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© Integrated trading provides both automatic 
matching trades for trading instruments between po- 
tential counterparties and video conversational nego- 
tiated trades for trading instruments between poten- 
tial counterparties using integrated keystations (202, 
204, 206, 208) which are selectively connectable 
together. Each of the keystations (202, 204, 206. 
208) includes a data input device, such as a key- 
board (240) and a mouse (242), and an integrated 
screen display (238), with the keyboard (240) and 
the display (238) being shared for both the automatic 
matching trades effectuated by the keystation (202, 
204, 206, 208) through a matching network (220) and 
the video conversational negotiated trades keystation 
(202, 204, 206, 208) through a separate conversation 
network (218). An integrated terminal controller (214, 
216) is provided as a common interface between the 
keystations (202, 204, 206, 208) and the separate 
networks (218, 220). Transaction data is provided 
between given keystations (202, 204, 206, 208) in 



the system (200) relating to both automatic matching 
transactions and video conversational negotiated 
trading transactions through the common integrated 
terminal controller (214, 216) which interfaces with 
the separate communication paths associated with 
the automatic matching trades (220) and the video 
conversational negotiated trades (218) effectuated by 
the keystation (202, 204, 206, 208). The integrated 
terminal controller(214, 216) comprises a conversa- 
tion server (252), a concentrator computer (254), the 
terminal computers (250) associated with the various 
keystations (202, 204, 206, 208) it serves, and a 
local area network (256) tieing them together. Initial 
access to both types of trades can be obtained at 
log on. A common ticket generation scheme for both 
types of trades is used so that trading tickets may 
be collected and communicated to a remote back 
office data base through the integrated terminal con- 
troller (214, 216), via the conversation server (252), 
irrespective of the type of trade completed. 
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INTEGRATED TRADING 



The present invention relates to effectuating 
trades of trading instruments both through auto- 
matic matching, in which buyers and sellers who 
are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video converstaional negotiated trades, in 
which buyers and sellers who are willing to trade 
with one another may do so through exchanging 
video conversational textual messages, and are 
particularly to the methodology of integrating these 
different types of trades in a system which enables 
individual keystations to accomplish both types of 
trades. 

Information retrieval systems for financial in- 
formation, such as stock market type of information 
and money market information, normally employ a 
transfer of data in a high performance, real time 
information retrieval, network in which update rates, 
retrieval rates and subscriber and/or user popula- 
tion are generally very high. An example of such a 
system is REUTERS DEALING SERVICE, which is 
used in the foreign exchange market, or GLOBEX, 
which is used by the Chicago Mercantile Exchange 
for electronic trading in the commodities market. 
Such systems, while providing rapid communica- 
tion capability between subscribers, have been pre- 
viously dedicated to one type of trading capability, 
albeit video conversation capability to effectuate 
negotiated trades through textual messages ex- 
changed between potential counterparties, such as 
in DEALING, or automatic matching capability to 
automatically effectuate trades between anony- 
mous potential counterparties meeting certain user 
specified criteria, such as in GLOBEX. Each of 
these types of systems have their place in the 
market and serve particular needs where appro- 
priate. However, because of world of trading of 
financial instruments and the requisite needs asso- 
ciated therewith are dynamic and rapidly change 
with changes in the surrounding circumstances, at 
one moment it may be desirable to trade anony- 
mously in an automatic matching environment 
while at the very next moment it may be desirable 
to openly trade in a video conversational negotiat- 
ing environment, or to do both, for the same or 
different trading instruments. Thus, although there 
have been successful trading systems doing one of 
these types of trades, there are no known prior art 
systems which effectively integrate both of these 
types of trades in a single system so as to permit a 
trader, using a single keyboard and display screen, 
to selectively switch between the two types of 
trading systems dependent on his own desires and 
needs at any given time in the trading environment. 



This is so despite the known technique in the prior 
art of tying common keyboard, such as described 
in US-A-4,404,551, in which a common keyboard is 
used to both communicate with multiple computer 

5 systems and multiplex or dynamically route or se- 
lect video displays on one or more VDUs from a 
plurality of simultaneously provided composite vid- 
eo signal inputs from these multiple computer sys- 
tems in response to unique keyboard generated 

70 character codes. 

In addition, despite known prior art systems 
which have attempted to integrate voice and data, 
such as disclosed in US-A-4,612,416; 4,598,367; 
4,653,045; 4,475,189; 3,344,401; and 4,635,251, 

75 none of these prior art systems, has integrated 
conversational trading, to enable negotiated trades, 
with automatic matching trades; to enable anony- 
mously matched trades, in a shared environment. 
For example, the system disclosed in US-A-4, 

20 598,367 is a financial quotation system employing 
a keypad input and a synthesized speech output, 
but does not integrate different types of trading 
transactions in a shared environment. Similarly, 
US-A-4, 509,167; 4,612,416; and 4,635,251, which 

25 are not directed to financial information per se, 
merely disclose systems which integrate voice mail 
in a telephone communication system. US-A- 
4,653,045 and 4,475,189 also disclose telephone 
systems which integrate voice and data, with these 

30 systems being used in telephone conferencing. 
US-A-3,344,401, discloses another type of tele- 
phone system in which voice is integrated with 
teletype for communicating with a remote data 
processor in an inquiry system; however, the dis- 
ss closed system is not utilized in a dynamic trading 
environment, such as one involving matching trans- 
actions and/or video conversational negotiated 
trades. 

Moreover, automatic matching trading systems 
40 are well known, such as described in US-A- 
3,573,747; 3,581,072; 4,412,287; 4,677,552; and 
4,674,044, as well as in EP-A-90305753; 0,399,850; 
90305763; and GB-A-2,227,625; 2,226,217; and 
2,224,141. However, although these prior art auto- 
45 matic matching systems are capable of automati- 
cally matching bids and offers, and may employ a 
centra! or host computer to accomplish this, such 
as disclosed in US-A-4,677,552; 4,674,044; and 
3,573,747; by way of example, they are incapable 
so of enabling video conversational negotiated trades 
to also occur, thereby requiring a totally different 
system to be employed if the trader desires to then 
execute such a trade. This can provide significant 
trading disadvantages to the trader. 

In addition, although the REUTERS DEALING 
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SERVICE, enables multiple conversations to be 
carried out by a given subscriber in real time and 
in association with data base retrieval of supple- 
mentary data, such as described in US-A-4 t 531,184 
and 4,525,779, by way of example, as well as in 5 
the aforementioned EP and GB specifications relat- 
ing to video conversational trading systems, none 
of these systems integrates an automatic matching 
trading system with one capable of providing video 
conversational negotiated trades. 10 

Apart from the above, there are no known 
trading systems of this type in which a keep alive 
signal is periodically provided to the system in 
order to notify the system that a given subscriber 
keystation is operating properly so that all out- 75 
standing active bids and offers associated with the 
keystation can be automatically deleted from the 
trading system if the keystation fails or is unable to 
provide the periodic keep alive signal to the sys- 
tem. This enables a trader who becomes mechani- 20 
cally locked out from active trading by keystation 
failure to be automatically removed from the trad- 
ing base so as to ensure that completed trades are 
accomplished only between active traders who are 
able to participate in the trading transactions which 25 
are occurring, whether they are anonymous trades 
or negotiated trades. 

Another feature lacking in the known prior art 
relates to the provision of a high speed, reliable 
system for providing a common ticket generation 30 
scheme for providing trading ticket information to a 
back office computer without continual polling, ir- 
respective of the type of deal or trade which has 
occurred. Although reliable ticket generation 
schemes are known, such as described in the 35 
above aforementioned EP and GB specifications 
relating thereto, and although methods and sys- 
tems for dynamically controlling the content of a 
local receiver data base from a transmitted data 
base in an information retrieval communication net- 40 
work for collecting financial information are also 
known, such as described in US-A-4,745,559, no 
prior art systems are known which provide com- 
mon ticket generation for automatic matching 
trades and for video converational negotiated 45 
trades, nor are any such prior art systems known in 
which both types of completed trades may be 
stored together for retrieval. 

Thus, there are no known prior art systems or 
methods which can readily combine the advan- 50 
tages, speed and reliability of both automatic 
matching and negotiated video conversational 
trades in a single system so as to provide the 
individual subscribers or keystations with maximum 
flexibility and optimal efficiency to effectuate the 55 
type of trade demanded by the time and circum- 
stances available. These disadvantages of the prior 
art are overcome by the method of the present 



invention. 

The present invention is set out in its various 
aspects in the independent claims of the present 
application. 

An example of the invention will now be de- 
scribed with reference to the accompanying draw- 
ings in which: 

Fig 1 is an overall system functional block dia- 
gram of a system capable of carrying out an 
integrated trading method; 
Fig 2 is a functional block diagram of a typical 
client site in the system of Fig. 1, illustrating a 
typical preferred integrated terminal controller; 
Fig 3 is a functional block diagram similar to 
Fig. 2, illustrating the portion of the presently 
preferred integrated terminal controller relating 
to the carrying out of video conversational nego- 
tiated trades; 

Fig 4 is a diagramatic illustration of a typical 

communication network for carrying out video 

conversational negotiated trades; 

Fig 5 is a diagramatic illustration of a typical 

terminal computer associated with a typical 

keystation in the system of Rg. 1; 

Rg 6 is a diagramatic illustration, similar to Rg. 

5, of a typical conversation server portion of the 

presently preferred integrated terminal controller 

of Rg. 2; 

Rg 7 is a functional block diagram, similar to 
Rg. 4, illustrating the network associated with 
carrying out automatic matching trades in the 
system of Rg. 1 ; 

Rg 8 is a functional block diagram of the net- 
work of Rg. 7 illustrating the flow of information 
in connection with the entry of a bid-and the 
entry of an offer in connection with effectuating 
automatic matching trades between potential 
counterparties in the system of Fig. 1 ; 
Rg 9 is a functional block diagram similar to 
Rg. 8, of the flow of information in the network 
of Fig. 7 in connection with a hit bid or trade in 
connection with the carrying out of automatic 
matching trades between potential counterpar- 
ties in the system of Rg. 1 ; 
Fig 10 is a diagramatic illustration of a typical 
integrated video screen display for a typical 
integrated keystation in the system of Rg. 1 
when the small font option has been selected; 
Fig 11 is a diagramatic illustration, similar to Rg. 
10, of a typical integrated video display screen 
layout when matching has been selected by the 
integrated keystation in Fig.1 ; 
Fig 12 is a diagramatic illustration, similar to Rg. 
10, of the video screen layout of Fig. 11 when 
the video conversational trade option has been 
selected with the display of Fig. 12 toggling with 
the display of Rg. 11; 

Fig 13 is a diagramatic illustration similar to Rg. 
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10 of a typical integrated video screen display 
for a typical integrated keystation in the system 
of Fig. t when the large font option has been 
selected and the matching trade option has 
been selected; 5 
Fig 14 is a diagramatic illustration similar to Fig. 
13, of a large font option for a typical integrated 
video screen display of a typical integrated 
keystation in the system of Fig. 1 when the 
video conversational trade option has been se- io 
lected, with the screen of Fig. 14 toggling with 
the screen of Fig. 13; 

Fig 15 is a diagramatic illustration of a typical 
integrated keyboard associated with a typical 
integrated keystation in the system of Fig. 1 ; 75 
Fig 16 is an illustration of a typical matching 
ticket produced as a result of a matching trade 
in the system of Fig. 1 ; 

Fig 17 is a diagramatic illustration, similar to Fig. 
16, of a typical conversation ticket produced in 20 
response to the completion of video conversa- 
tional negotiated trade in the system of Fig. 1; 
Fig 18 is a diagramatic state diagram of the 
sequence of operations associated with log on 
and log off a typical integrated keystation in the 25 
system of Fig. 1; 

Figs 19-20 comprise a logic flow diagram of the 
log on/log off sequence of operations illustrated 
in the state diagram of Fig. 18; 
Figs 21-24 are diagramatic illustrations of typical 30 
integrated video screen displays for a typical 
integrated keystation in the system of Fig. 1, 
illustrating the integrated trading capabilities of 
the system of Fig. 1, with Fig. 21 illustrating a 
typical integrated video display in which both 35 
information relating to automatic matching 
trades and information relating to video con- 
versational negotiated trades is present on the 
screen, but no trade has occurred with that 
keystation, with Fig 22 illustrating the screen of 40 
Fig. 21 with information about to be transmitted 
in connection with completion of a matching 
transaction, with Fig. 23 illustrating the automatic 
matching trade represented in Fig. 21 as having 
been executed and match notification having 45 
been received by the keystation, and with Fig 24 
illustrating the integrated display screen of Fig. 
21 when a video conversation negotiated trade 
has been completed; 

Fig 25 is a logic flow diagram of the operation of so 
a typical integrated keystation in the system of 
Fig. 1 in response to receipt of a match notifica- 
tion signal; 

Fig 26 is a logic flow diagram, similar to Fig. 25, 
of the operation of a typical integrated keysta- 55 
tion in the system of Fig. 1 in response to 
receipt of a match ticket or conversation ticket; 
Figs 27-29 are logic flow diagrams, similar to 



Fig. 25, illustrating the operation of a typical 
integrated keystation in the system of Fig. 1 with 
respect to the keep alive feature, with Rg. 27 
illustrating the operation of the integrated key- 
board, and Figs. 28 and 29 illustrating the op- 
eration of the terminal computer portion of the 
integrated keystation; 

Fig 30 is a functional block diagram illustrating 
the flow of information in connection with a 
typical matching transaction; 
Rg 31 is a diagramatic illustration of a portion of 
the trading ticket output process utilizable in the 
system of Rg. 1 concerned with the ticket out- 
put protocol; 

Fig 32 is a logic flow diagram of a ticket output 
process; 

Rg 33 is a logic flow diagram of the operation of 
the integrated terminal controller when a new 
trading ticket has been generated in accordance 
with the trading ticket output process of Rg. 32; 
Rg 34 is a logic fiow diagram of the operation of 
the database server portion of the integrated 
terminal controller in the system of Fig. 1 with 
respect to requests for tickets received by the 
database server from a back office computer; 
Fig 35 is a logic flow diagram of the data 
display application for initiating a fast conversa- 
tional contact message using the screen pointer 
in a typical integrated keystation in the system 
of Fig. 1 ; and 

Rg 36 is a logic flow diagram of the conversa- 
tion application processing of a fast conversa- 
tional contact message initiated in accordance 
with Rg. 35 for expanding the contact message 
and establishing conversational contact in the 
system of Rg. 1. 

An integrated trading system 200, as will be 
described in greater detail hereinafter, is capable of 
effecting trades of trading instruments both through 
automatic matching, in which buyers and sellers 
who are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video conversational negotiated trades, in 
which buyers and sellers who are willing to trade 
with one antoher may do so through exchanging 
video conversational textual messages. Individual 
integrated keystations, with four such integrated 
keystations 202, 204, 206 and 208 being shown by 
way of example in Rg. 1, are able to accomplish 
both types of trades. In addition, as will be de- 
scribed in greater detail hereinafter individual 
keystations which are only capable of performing 
one of these types of trades can trade with another 
keystation of that type or with an integrated keysta- 
tion which is capable of performing both types of 
trades. In this regard, as shown and preferred in 
Rgs. 1 and 2 ? an integrated terminal controller with 
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two such client sites 210, 212 being illustrated by 
way of example, in Fig. 1. One such integrated 
terminal controller 214, 216 is illustrated at each 
client site 210, 212, respectively, by way of exam- 
ple, in Fig. 1. 

As shown and preferred in Figs. 1 and 2, a 
typical integrated terminal controller 214, may ac- 
commodate a plurality of integrated keystations 
202, 204, by way of example, and is the system 
interface for these keystations 202, 204 with the 
other keystations 206, 208 in the system 200 in 
order to enable the different types of trades to be 
effected with these integrated keystations 202, 204, 
206, 208. As shown by way of example in Fig. 1, 
each type of trade, namely video converstationa! 
negotiated trades and automatic matching trades, 
has its own associated communication network 
218, 220 respectively, since the population of in- 
dividual subscribers involved in automatic matching 
trades. In this regard, there is a host computer 222 
associated with the routing of conversational trade 
and there is a separate matching host computer 
224 which is actually responsible for the matching 
trades which occur through the matching commu- 
nication network 220, such as described in greater 
detail in the above European publications. Suffice it 
to say that the present control and operation of 
automatic matching trades is preferably the same 
as described in these EP and GB specifications, 
with the exception of the involvement of the in- 
tegrated terminal controller 214, 216, with reference 
to a typical terminal controller 214 to be described 
in greater detail hereinafter, and the use of the 
integrated keystation 202, 204, 206, 208 with the 
operation of a typical integrated keystation 202 to 
be described in greater detail hereinafter. 

A common ticket generation scheme and ticket 
output feed to the back office computer is used for 
both the video conversational negotiated trades 
performed by the system 200 and the automatic 
matching trades performed by the system 200. 
Similarly, with respect to the video conversational 
negotiated trades performed by the system 200. 
these trades are preferably performed in the same 
manner as described in GB-A-2,226,217 and GB-A- 
2,227,625, with the exception, once again of the 
involvement of the integrated terminal controller 
214, 216 and the integrated keystations 202, 204, 
206, 208, which enables both this type of trade and 
the automatic matching trades to be integrated in 
the same system 200 and provided on a common 
video display 238, and which provides a common 
ticket generation scheme for both types of trades. 
With respect to the common ticket generation 
scheme, except for the differences to be described 
hereinafter, the ticket generation in the system 200, 
which also describes the provision of the ticket 
output fee to the back office computer. 



As shown in Fig. 1, each of the integrated 
terminal controllers 214, 216, has an associated 
ticket printer 226, 228 respectively, and an asso- 
ciated conversation printer 230, 232, respectively, 

5 as well as a ticket output feed 234, 236, respec- 
tively, to its associated back office computer. With 
respect to the individual integrated keystations 202, 
204, 206, 208 to be described in greater detail 
hereinafter, a typical integrated keystation 202 pref- 

70 erably has an integrated screen display 238, to be 
described in greater detail hereinafter and illus- 
trated by way of example, in Figs. 10-14 and Rgs. 
21-24, an integrated keyboard 240, such as the 
typical keyboard illustrated in Fig. 15, and a con- 

75 versational mouse 242 which may preferably be 
used to accomplish fast conversational contact, by 
way of example, such as in the manner described 
in GB-A-2,227,625, and illustrated, by way of exam- 
ple in Figs. 35-36 which correspond to Rgs. 11-12 

20 of GB-A-2,227,625. 

As shown in Fig. 2, the integrated terminal 
controller 214 comprises a terminal computer 250 
associated with each keystation. The terminal com- 
puter 250 is preferably a conventional computer 

25 configuration, such as an 80386 Intel 302 computer 
for each integrated keystation 202, 204, 206, 208. 
In addition, the integrated terminal controller 214 
also preferably includes a conversation server com- 
puter 252, such as one comprising another 80386 

30 Intel 302 computer, and which is shown in greater 
detail in Fig. 3, and a concentrator computer 254, 
such as a MICRO VAX 2000 computer, for commu- 
nicating with the matching host computer 224 
through the matching communication network 220. 

35 The conversation server 252, the concentrator 
computer 254, and the terminal computers 250 
associated with the various integrated keystations 
202, 204, for example, are all preferably tied to- 
gether through a conventional local area network 

40 256, such as an Ethernet network, with the con- 
centrator computer 254 preferably communicating 
with the conversation server 252 via the keystation 
terminal computer 250 connected to the local area 
network 256. As shown and preferred in Rgs. 2 

45 and 3, and as will be described in greater detail 
hereinafter, the conversation server 252, which is 
shown in greater detail in Rg. 6, not only handles 
video conversational trading, but preferably ties 
together, in the integrated system 200, the printing 

so and ticket generation for both automatic matching 
trades and video conversational negotiated trades 
performed by a given integrated keystation 202, 
204 associated with that integrated terminal control- 
ler 214, and is the interface with the associated 

55 back office computer for the ticket output feed for 
trades performed at that client site 210, irrespective 
of the type of trade performed. 

As shown and preferred in Fig. 3, although the 
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conversation server 252 is represented by only one 
block in Fig. 2, in reality it may be comprised of a 
line server 264 which enables, for example, the 
provision of context sensitive prompts during con- 
versational trading, such as described in greater 
detail in GB-A-2,226,217. Thus, the conversation 
server 252, such as illustrated in Fig. 6, performs 
several different functions in the system 200 of the 
present invention. The conversation server 252 
handles communications with the conversation 
comunnication network 218, such as DEALING, 
maintains a database with respect to DEALING 
conversations, trade logs and tickets, drives various 
printers 226, 230, analyzes conversations in 
progress, and generates a serial ticket output feed, 
via path 234, for provision of this feed to the back 
office computer. By way of example, in accom- 
plishing this task, the conversation server computer 
252, may, by way of example comprise at least 4 
megabytes of memory, a 40 megabyte hard disk, a 
high density floppy, an Ethernet card with 512 
kilobytes of memory, conventional RS232 Serial 
Connections, an STB VGA extra memory video 
card generating a TTL output, and the appropriate 
software to communicate with the conversation 
communication network 218. These components 
are illustrated, by way of example, in Rg. 6. With 
respect to the associated printers 226, 230, the 
conversation printer 230 preferably prints conversa- 
tions as they are completed, whereas the ticket 
printer 226 preferably prints a single ticket for each 
matching trade as well as each confirmed video 
conversational negotiated trade. Of course, other 
printers may be associated with the integrated ter- 
minal controller 214, such as an audit trail printer 
280 or other standby printers if desired. With re- 
spect to the typical terminal computer 250, such a 
terminal computer 250 is illustrated in further detail, 
by way of example, in Rg. 5. Thus, by way of 
example, the terminal computer 250 such as an 
Intel 302 PC, which may also be employed for the 
conversation server 252 as illustrated in Rg. 6, 
preferably includes an RS232 input for a serial 
keyboard 240 and a serial mouse 242, a 51 2K 
Ethernet card, a conventional device for driving an 
analog screen 238, a 40 megabyte hard disk, and 
at least 3 megabytes of memory. It should be 
noted, that the terminal computer 250 illustrated in 
Rg. 5 is merely illustrated by way of example, and 
other conventional computers capable of use with 
the system 200 may also be employed instead of 
or in conjunction with terminal computer 250. 

It should be noted with reference to Fig. 2 that, 
although only one conversation server 252 is illus- 
trated as being connected to the local area network 
256, if desired, a plurality of conversation servers 
252 can be connected to the same section of the 
Ethernet Network 256, with there still being a single 



concentrator computer 254 for supporting matching 
connected to the local area network 256. By way of 
example, each conversation server 252 may sup- 
port up to 12 keystations for conversational trading 

5 and matching trades, with the concentrator com- 
puter 254, by way of example, being a Micro VAX 
2000 computer having a Ethernet interface, a hard 
disk, a pair of Asynchronous Serial lines to the 
matching communication network 220, and appro- 

10 priate software, such as referred to in the afore- 
mentioned EP and GB specifications. It should be 
noted that, by way of example, in the instance of 
12 keystations being associated with a given in- 
tegrated terminal controller 214, the 12 keystations 

15 need not all be supported by the same conversa- 
tion server 252, as mentioned above, even though 
the 12 keystations could be supported by a single 
concentrator computer 254. 

As will be described with reference to Rgs. 10 

20 - 14, different screen layouts for the integrated 
screen display 238 may be provided, with Fig. 10 
illustrating the small font option preferably for use 
with large video screens such as 12 - 14 inch 
screens, and with Rgs. 13 and 14 illustrating the 

25 large font option preferably for use with smaller 
video screens such as 10 inch screens or when the 
user requires a simple display. Rgs. 11 and 12 
illustrate the screen layout of the integrated screen 
display 238 in which, by way of example, a 14 row 

30 general display area is provided by overlaying the 
matching trade and conversational trade windows 
in the display, with Rg. 11 illustrating the integrated 
screen display 238 when matching has been se- 
lected by the user at the keystation, and with Rg. 

35 12 illustrating the integrated screen display 238 
when conversational trading has been selected by 
the user at the keystation, with the integrated 
screen display 238 toggling between the layout 
illustrated in Rg. 11 and the layout illustrated in 

40 Rg. 12 depending on the option selected. Prefer- 
ably, any of the screen layouts illustrated in Rgs. 
10-14 may be selected by the user at the keysta- 
tion for providing the desired integrated screen 
display 238. in this regard, it should be noted that 

45 the keystation may be run under commercially 
available windowing software, such as Microsoft 
Windows 386 version 2.1, DOS 3.3 and the Win- 
dows version of the Workstation Environment 
(WSE). In the screen layout for the integrated 

so screen display 238 illustrated in Rg. 10, the current 
entries in the market for potential automatic match- 
ing trades are preferably contained in area 260 with 
the results of the particular keystation' s recent 
automatic matching trade activity preferably being 

55 contained in the area immediately below and given 
reference number 262. As illustrated in Fig. 10. in 
the area immediately below that is the window 
which contains conversational trading activity and 
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may. by way of example, contain up to four such 
separate trading conversations of the type referred 
to in the aforementioned patents and EP and GB 
specifications relating to conversational trading. 
This area has been given reference numeral 264. 
Immediately to the right of that area in the screen 
layout illustrated in Rg. 10 is an area designated 
for displaying incoming calls as well as conversa- 
tion analysis summaries, such as referred to in the 
aforementioned patents and EP and GB specifica- 
tions, with conversation analysis summary being 
described and referred to in the aforementioned 
GB-A-2,226,217, and with this area being given 
reference numeral 266. In connection with the dis- 
play of multiple trading conversations in area 264, 
when conversational trading is selected by the in- 
tegrated keystation given the screen layout of Rg. 
10, preferably there is provision for a heading and 
at least 7 lines of the current conversation, and at 
least a heading and 1 line of text for up to three 
more trading conversations. Immediately below 
area 264 is a display area for Dealing or conversa- 
tional trading command responses, with that area 
being designated with reference numeral 268. Be- 
low that area is an area designated as the general 
display area, given reference numeral 270, which 
may preferably contain other market related in- 
formation, such as the REUTER MONITOR page. 
The same areas are preferably provided in the 
screen layouts illustrated in Rgs. 11 and 12 with, 
however, the size of the general display area 270 
being increased so as to provide more room for the 
general display area 270 in the screen layout in the 
integrated screen display 238. As can be seen in 
Rgs. 11 and 12, which relate to the same screen 
layout in which the general display area 270 is 
larger, such as 14 rows as compared with the 9 
rows provided in the example of Rg. 10, the larger 
size for the general display area 270 is accom- 
plished preferably by overlaying the matching trade 
area 260 and the conversational trade area 264, 
with Rg. 11 illustrating the screen layout when a 
matching trade option has been selected by the 
integrated keystation and with Rg. 12 illustrating 
the same screen layout when a conversational 
trade option has been selected by the integrated 
keystation. In this regard, it should be noted that in 
the option illustrated in Rg. 11, the conversational 
trade area 264 is, by way of example, 15 rows in 
height, and the matching trade area 260 is 7 rows 
in height, whereas in the option illustrated in Rg. 
12, the conversational trade area 264 has been 
increased to 22 rows, by way of example, by 
overlaying the 7 rows previously used for the 
matching area 260. Thus, as previously mentioned, 
the integrated keystation toggles between the 
screen layout of Rg. 11 and the screen layout of 
Rg. 12 depending on the trade option selected by 



the integrated keystation. With respect to the 
screen layouts illustrated in Rgs. 13 and 14 for the 
integrated screen display 238, these screen layouts 
preferably have the same windows as the afore- 

5 mentioned screen layouts with, however, the num- 
ber of rows in various areas being reduced so as to 
accommodate larger characters in the display. In 
this regard, in Rg. 13, which illustrates the in- 
tegrated screen display 238 layout when matching 

w has been selected, the incoming calls area 266 is 
reduced in size as is the conversational trade area 
264, and the general display area 270 is the same 
size as in the option of Rg. 10. In Rg. 14, when the 
conversational trade option has been selected, the 

is matching trade area 260 is overiayed by the con- 
versational trade area 264 which is increased in 
size, by way of example, from the 6 rows of Rg. 13 
to 13 rows in Rg. 14, and the incoming calls area, 
which is also used for conversation analysis sum- 

20 mary, 266 is increased in size. Preferably, the 
integrated screen display 238 has a high resolution, 
such as 640 pixels horizontally by 480 pixels verti- 
cally, which is in line with the normal VGA stan- 
dard, with the video being conventionally supplied 

25 by a Windows 386 driver and the STB VGA card in 
the terminal computer 250. 

Referring now to Rg. 15, an integrated key- 
board 240 contains keys which will enable the user 
to participate in both matching trades as well as in 

30 conventional trades in the system 200. For exam- 
ple, such a keyboard 240 may be obtained from 
Reuters, the assignee herein, under the designation 
DK101 or AK122/3, with all of the integrated key- 
boards 240 on a particular integrated terminal con- 

35 troller 214 preferably being of the same type. The 
system 200 uses keep alive signals from the in- 
tegrated keyboard 240 in order promptly to detect 
keyboard failure since such failure would effectively 
mechanically disable the trader or keystation from 

40 participating in both matching and/or conversational 
trades through use of the system 200. The keep 
alive signal is preferably a special character which 
is sent to the terminal computer 250 of the keysta- 
tion, at a predetermined periodic interval, such as 

45 . every 4 or 5 seconds. This procedure is diagra- 
matically illustrated in Rg. 27. When the terminal 
computer 250 receives these special keep alive 
character, it preferably increments a keep alive 
counter, with this procedure being illustrated in Rg. 

so 28. The terminal computer 250 also preferably 
checks at a periodic interval, such as every 5 
seconds, whether the keep alive counter has been 
incremented. If the counter has not been incre- 
mented from the previous count, this indicates to 

55 the terminal computer 250 that the keep alive sig- 
nal or special character has not been received and 
that, consequently, the integrated keyboard 240 
may have failed. This procedure is illustrated in 
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Fig. 29. When the terminal computer 250 detects 
that the keyboard 240 has failed, the keystation 
removes all entries which it has placed in the 
matching market in connection with potential auto- 
matic matching trades and automatically terminates 
all its current conversations associated with con- 
versational trading, and logs off. If desired, an 
alarm can also be provided at the keystation on the 
screen 238 indicating that the keyboard has failed. 
Thus, the keep alive signal periodically provided 
from the integrated keyboard 240 provides a heart- 
beat from the keyboard 240 to the terminal com- 
puter 250, which has been conventionally pro- 
grammed in accordance with the procedures illus- 
trated in Figs. 28 - 29, and which automatically 
removes the offers and bids associated with that 
keystation from the matching host computer 224 
when it is detected that the integrated keyboard 
240 has failed by failing to provide an appropriate 
heartbeat or keep alive signal to the terminal com- 
puter 250. Summarizing the above, when a keep 
alive signal is not provided and the terminal com- 
puter 250 detects that it has not been provided 
because the keep alive counter has not been incre- 
mented, four actions occur; namely, the user is 
informed that the keyboard 240 has failed, the user 
is logged off the keystation, contact is ended in all 
conversations which were active at the time in the 
conversational trading portion of the integrated 
trading system 200, and all prices which had been 
input to the matching host computer 224 by that 
keystation in connection with the automatic match- 
ing trading portion of the integrated system 200 are 
automatically removed from the matching host 
computer 224 database. Preferably, as shown and 
preferred in Fig. 29, if a keep alive signal is not 
detected in the first instance, then the terminal 
computer 250 retries again. If it is not detected 
after the second try, or second beat, then the 
terminal computer 250 indicates that the keyboard 
240 has failed. In this regard, if a mouse 242 is 
provided at the keystation, preferably, the keysta- 
tion may continue to operate if the mouse 242 fails 
as long as the integrated keyboard 240 is still 
functioning. 

The function of logging on to the matching 
communication network 220 in order to effect auto- 
matic matching trades and to the conversation 
communication network 218 in order to effect video 
conversational negotiated trades is integrated in the 
system 200. Fig. 18 is a state diagram illustrating 
the sequence of operations in connection with the 
integrated log on/log off to the system 200, with 
Figs. 19-20 illustrating a logic flow diagram of the 
logic operations performed by the system 200 in 
connection with the sequence of operations illus- 
trated in Fig. 18. Preferably, in order for the user or 
keystation to log on to the system 200, a user 



identifier is required as well as, preferably, a user 
password. Preferably, the user identifier is part of 
the set up data in the integrated terminal controller 
214 and must be entered correctly on log on for 

s the user. When this information is entered, the 
server database 262 and the integrated terminal 
controller 214 is accessed in order to obtain the 
subscriber name and to check the user l.D. If the 
user l.D. is known in the system 200, then the 

w terminal or keystation 202 for example, is checked 
to see if it has been permissioned for matching. If it 
has, then the integrated keystation, 202 by way of 
example, tries to log on to the matching commu- 
nication network 220 with the input password, sub- 

75 scriber name and user l.D. If log on succeeds to 
the matching communication network 220 the 
keystation 202 has now been logged on to both the 
conversation communication network 218 and the 
matching communication network 220, since log on 

20 to the conversation communication network 218 
has not been inhibited, if, however, the keystation 
202 cannot log on to the matching communication 
network 220, then the keystation 202 is preferably 
disconnected from both the matching communica- 

25 tion network 220 and the conversation communica- 
tion network 218 and the log on procedure is 
repeated, starting with the insertion of the user l.D. 
and password. If, however, matching communica- 
tion for the keystation 202 is not enabled, as op- 

30 posed to attempting to log on and failing to log on, 
then conversation communication may still be en- 
abled with the conversation communication network 
"218. 

Referring to the log off procedure, assuming 

35 matching communication has not been enabled but 
conversation communication with the conversation 
communication network 218 had been enabled at 
the time of the log off request, then the system 200 
checks to see if a conversation is in progress. If a 

40 conversation is in progress then the keystation 202 
may not log off. However if a conversation is not in 
progress, then the keystation 202 may be discon- 
nected from the conversation communication net- 
work 218. Similarly, if matching communication had 

45 been enabled and the keystation 202 had logged 
on to both the matching communication network 
220 and the conversation communication network 
218, the keystation 202 still could not log off if a 
conversation was in progress with that keystation 

so 202. The keystation 202 would have to first termi- 
nate the conversation. Furthermore, as shown and 
preferred in Fig. 20, if a log off request were 
received from that keystation 202 which had been 
logged on to both the communication network 220 

55 and the conversation communication network 218, 
then the system 200, and particularly the asso- 
ciated integrated terminal controller 214, would first 
determine whether any trading conversation or 
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matching was in progress associated with that 
keystation 202 and, assuming it was not then in 
progress, the terminal controller 214 would then 
determine whether there were any outstanding 
matching tickets expected as a result of trades 
which had been completed but had not yet had a 
ticket generated. If there were no outstanding 
matching tickets expected, then the keystation 202 
could disconnect from both matching and con- 
versational trading. If however, there were outstand- 
ing matching tickets expected, then preferably the 
user would be given the option to confirm a log off, 
or cancel a log off, or wait for the tickets. If the 
user confirmed a log off or had received the tickets 
after waiting for them, the user could then dis- 
connect from matching and conversational trading. 
If the user merely cancel led the log off, then 
conversation and matching trading would still be 
enabled. This would also be true if a conversational 
or matching trade associated with that keystation 
were still in progress. As also shown and preferred 
in Fig. 19, if the keyboard 240 either failed in any 
state in the sequence of operations or was discon- 
nected during any state in the sequence of oper- 
ations, the keystation 202 would be disconnected 
from both matching and conversational trading until 
reconnection of the keyboard 202. It should be 
noted from the above, that a keystation 202 may 
solely log on to conversational trading or automatic 
matching trading if that is its capability or desired 
intent. The purpose of the integrated log on is to 
enable a single keystation 202 to log on to both 
different types of trading systems, assuming it has 
that capability, with a single log on procedure. The 
software associated with the log on/log off proce- 
dure illustrated in Figs. 18 - 20 is contained, by 
way of example, in Table A annexed hereto as an 
Appendix, and is written in C language for use with 
the 80386 terminal computer 250 in which this 
software is resident. 

Referring now to Figs. 21 - 24, typical screen 
displays for the integrated screen display 238 are 
shown which contain trading information in connec- 
tion with both matching trades and video conversa- 
tional negotiated trades by the keystation 202 after 
it has logged on to both the matching communica- 
tion network 220 and the conversation communica- 
tion network 218. Fig. 21 illustrates the presence of 
both conversational trading data and matching trad- 
ing data on the integrated screen display 238. Fig. 
22 illustrates the same integrated screen display 
238 when the YOURS key on the keyboard 240 of 
Fig. 15 has been depressed and the YOURS dia- 
logue box is about to be transmitted. Fig. 23 illus- 
trates the same integrated screen display 238 
when a matching trade has been automatically 
executed and a match notification has been pro- 
vided from the matching host computer 224 to the 



integrated terminal controller 214 associated with 
the keystation 202. The logic flow diagram illustrat- 
ing the operation of the integrated terminal control- 
ler 214 in response to such a match notification is 

5 shown in Fig. 25 to be described in greater detail 
hereinafter. Fig. 24 illustrates the same integrated 
screen display 238 with, this time, a conversational 
negotiated trade having been completed as shown 
on the screen and in the conversation analysis area 

70 266. 

The logic flow diagram of Fig. 25 may be 
accomplished by conventional programming of the 
integrated terminal controller 214. When the match 
acknowledgment, to be described in greater detail 

75 with reference to Fig. 9 and EP-A-90305753 is 
received from the matching host computer 224, the 
match is displayed on the integrated screen dis- 
play 238 which was a party to the matching trans- 
action. In addition, an audit trail message is sent to 

20 the database server 262 which forms part of the 
conversation server 252 of the integrated terminal 
contorller 214 and the audit trail is stored at the 
database server 262. A reply with the match num- 
ber is sent to the keystation and when the match 

25 number is received by the keystation 202 a match 
acknowledgement, termed MATCH ACK, is sent to 
the matching host computer 224. As further shown 
and preferred in Rg. 25, the database server 262 
may also be preferably connected to the audit trail 

30 printer 280 for printing of audit messages. The 
procedure for printing such audit trail messages is 
also illustrated in the logic flow diagram of Rg. 25. 

Rg. 26 is a logic flow diagram of the operation 
of the integrated terminal controller 214 in re- 

35 sponse to receipt of a matching ticket or conversa- 
tion ticket at the completion of an automatic match- 
ing trade or video conversation negotiated trade, 
respectively, and may, of course also be imple- 
mented by conventional programming of the in- 

40 tegrated terminal controller 214. When a match 
ticket is received at the integrated keystation 202 
from the matching host computer 224, the match 
ticket is sent to the database server 262 contained 
in the conversation server 252 of the integrated 

45 terminal controller 214 in the form of what is 
termed a pseudo conversation, with a typical 
matching ticket corresponding to such pseudo con- 
versation being illustrated in Fig. 16. This match 
ticket is then stored at the database server 262 and 

so can be accessed to support review of displays on 
the integrated screen display 238 via the terminal 
computer 250 or to support retrieval of tickets over 
the ticket output feed 234 to the back office com- 
puter. Similarly, when a conversation ticket is con- 

55 firmed at the completion of a video conversational 
negotiated trade, the conversation ticket, which 
may be in the form shown by way of example in 
Fig. 17, js sent to the database server 262 con- 
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tained in the conversation server 252 of the in- 
tegrated terminal controller 214 along with the con- 
versation, the ticket is then stored at the database 
server 262 with the conversation and, like the 
matching ticket, may be accessed to support re- 
view of displays on the integrated screen display 
238 via the terminal computer 250 and to support 
retrieval of tickets over the ticket output feed 234. 
Fig. 26 also illustrates the operation of the printing 
of a ticket, either a match ticket or a conversation 
ticket, by the ticket printer 226 utilizing the ticket 
data stored at the database server 262. 

Apart from the differences described above 
with respect to the employment of the integrated 
terminal controller 214 and integrated keystation 
202 so as to enable the integration of automatic 
matching trades and video conversational negoti- 
ated trades in the system 200, the function and 
operation of the various components of the system 
200 relating to the conversation commnication net- 
work 218 and matching communication network 
220 are preferably the same as described in the 
respective aforementioned patents and EP and GB 
specifications which relate to these functions. How- 
ever, for purposes of clarity, certain portions of 
these patent applications shall be repeated herein 
with respect to Figs. 3 and 4 relating to video 
conversational negotiated trades; Figs. 7-9 and 30 
relating to automatic matching trades; and Figs. 31- 
34 relating to the ticket generation scheme for 
providing the ticket output feed via path 234 or 
236. 

Referring now to Figs. 3 and 4, as previously 
mentioned, the integrated trading system 200, pro- 
vides conversation analysis with respect to the 
video conversational negotiated trades effected by 
the system 200, with this conversation analysis 
being summarized in area 266 of the integrated 
screen display 238. This analysis is preferably ac- 
complished in the same manner as described in 
the aforementioned GB-A-2,226,217, in which con- 
text sensitive prompts are employed, with the con- 
versation analysis software driving the analysis 
driven prompts and letting the user know in real 
time where the user is in the conversation that is 
going on between counterparties, such as foreign 
exchange traders, so that the appropriate prompt 
selection menu may be employed based on the 
analysis of the key points in the conversation as it 
proceeds in real time. This real time conversation 
analysis, as described in GB-A-2,226,217, also en- 
ables the preparation of Dealing or conversation 
tickets in real time while the deal is being arranged 
through the use of artificial intelligence techniques 
to analyze the conversation dialog and generate 
the ticket. Thus, as described in GB-A-2,226,217, 
this is accomplished in an expert type of system. 
The context sensitive or analysis driven prompts 



are preferably employed to speed up the dealer 
input in connection with video conversational nego- 
tiated trades in system 200 of the present invention 
since time is generally of the essence, such as in 

s foreign exchange dealings. Of course, the system 
200 need not be limited to foreign exchange deal- 
ing and may be used in connection with any type 
of video communication where rapid input of con- 
versation information is desired. Of course, as is 

to also described in GB-A-2,226,217, the system may 
be employed for data capture of offline deals as 
well. Because of this conversation analysis, the 
system 200, is capable of generating error mes- 
sages to the user to alert the user if an inconsis- 

15 tency is detected in the conversation being ana- 
lyzed in connection with a video conversational 
negotiated trade, such as if the value date is in- 
proper or the range of prices is inproper, by way of 
example. As described in GB-A-2,226,217, apart 

20 from the conversation analysis driven prompts and 
associated features, the system is substantially 
similar to other conversational video systems de- 
veloped by the assignee herein and described in 
the aforementioned GB-A-2,227,625. In this regard, 

25 the conversation communication network 218 is 
preferably basically the same type of communica- 
tion network as illustrated in Fig. 13J, by way of 
example, of US-A-4,525,779 and the same refer- 
ence numerals have been used in Fig. 4 as are 

30 used in US-A-4,525,779 for like functioning compo- 
nents such as for the concentrators 48 and 110, 
and for the nodes 44 and 42, but with the host 
computer given reference number 38 in Fig. 13J, of 
US-A-4,525,779, and with the storage device hav- 

35 ing been given reference numeral 205 in the exam- 
ple of Fig. 4. The London Taker in Fig. 4 is 
assumed to be the integrated terminal controller 
216 at client site 212 and the New York Maker is 
assumed to be the integrated terminal controller 

40 214 at client site 210. Of course, other packet 
switching communication networks could be em- 
ployed for the conversation communication net- 
works 218 in place of the network illustrated in Fig. 
4. The terminal controller shown in Fig. 13J of US- 

45 A-4,525,779 is replaced by the integrated terminal 
controller 214 or 216 in the system of Fig. 1, with 
this integrated terminal controller preferably includ- 
ing a conversation analyzing terminal controller 
portion 214a, such as illustrated in Fig. 3, which 

50 enables real time conversation analysis of the vid- 
eo conversations between, for example, the New 
York Maker at client site 210 and the London taker 
at client site 212, and the provision of context 
sensitive analysis driven prompts, in this regard, 

55 and as described in the aforementioned GA- 
2,227,625, conversation tickets may be printed 
based on real time conversation analysis. In addi- 
tion, as was also previously mentioned, the in- 
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tegrated keystations 202, 204, 206, 208 preferably 
also have a conventional mouse 242, such as the 
mouse described in the aforementioned Gb-A- 
2,227,625, such as for providing the fast contact 
features described therein and illustrated in Figs. 
35-36 which correspond to Figs. 11-12 of GB-A- 
2,227,625. If these features are not desired, the 
mouse 242 may be omitted.. Moreover, it should be 
noted, that both parties to a conversation need not 
have an integrated terminal controller 214, 216 
containing a conversation analyzing terminal con- 
troller portion 214a, in that the analysis server 264 
may be omitted, however, the party will then not 
have the benefit of real time conversation analysis 
to provide context sensitive or analysis driven 
prompts or automatic ticket generation or inconsis- 
tency notification based on such real time con- 
versation analysis. 

With respect to the conversation anaylzing ter- 
minal controller portion 214a illustrated in Fig. 3, 
the line server 260, database server 262 and con- 
versation analysis server 264 are all preferably 
80386 computers, such as a COMPAQ 80386 
based computer. In addition, as was previously 
mentioned, the terminal computers 250 are also 
preferably 80386 based computers, each of which 
provides outputs to its associated integrated screen 
display 238, integrated keyboard 240, and mouse 
242. The previously mentioned local area network 
256 further permits communication between appro- 
priate ones of the various computers 260, 262, 252 
and 250 in accomplishing the conversation analy- 
sis, context sensitive prompts, inconsistency alert, 
and automatic ticket generation functions of the 
system 200. The line server 260 preferably serves 
as an interface between the terminal computers 
250 and the appropriate concentrator 48 or 110 in 
the conversation communication network 218. The 
functions of the database server 262 have already 
been described with respect to the integrated ter- 
minal controller 214. As for the conversation analy- 
sis server 264, this server 264 preferably stores the 
conversation analysis software, such as the soft- 
ware described in detail in the aforementioned GB- 
A-2,227,625 and analyzes the conversation in real 
time and provides the desired context sensitive or 
analysis driven prompts to the Maker or Taker's 
screen 238, depending on whom the conversation 
analyzing terminal controller portion 214a is asso- 
ciated with at the time, provides conversation tick- 
ets to the database server 262 associated with it, 
and alerts the user to inconsistencies in the con- 
versation by providing such alerts to the integrated 
screen display 238. Of course, although in the 
example of Fig. 3, separate servers 260, 262 and 
264 are shown as comprising the conversation 
server 252 of the integrated terminal controller 214, 
these servers can be combined into a single com- 



puter, if desired, with each keystation 202, 204, 
206, 208 still being supported by a dedicated ter- 
minal computer 250 and with, as previously men- 
tioned, these keystation terminal computers 250 

5 being linked to the servers 260, 262, 264 by the 
conventional local area network 256. Preferably, 
communication over this local area network 256 
uses a virtual connection such as provided by the 
MS-NET standard variant. In addition, preferably all 

10 of the data about each conversation in progress, 
such as up to 24 such conversations for a given 
terminal controller 214, by way of example, is held 
in a global array with each element in this array 
pointing to a structure of type CONVDATA in ac- 

15 cordance with the software illustrated, by way of 
example, in the aforementioned GB-A-2,227,625. 
This is a type which holds the various network 
handles associated with the conversation, the text 
buffer for the conversation, and so on. It also 

20 preferably includes an element identified as 
SAVEDDATA of type ANALYSISDATA, which is 
used to store the state of the conversation analysis. 
The conversation analysis is driven by the receipt 
of packets of text from the various keystations 202, 

25 204, 206, 208 comprising the subscriber population 
of the conversation communication network 218. 
These successive chunks of text arrive in AN- 
ALYSE TEXT PACKETS which are directed to the 
correct procedure by the environment, which has 

30 been informed of the destination of the input mes- 
sages by a call to NetRegisterRepiy in the proce- 
dure Ov-main in section caserver.c in the software 
described in the aforementioned GB-A-2,227,625. 
The incoming packets of text are directed to the 

35 procedure fn ReplyAnalysisMessages in the sec- 
tion camesage.c. When an ANALYSE TEXT packet 
is received for a conversation, (Current Conv) is set 
to point to the CONVDATA structure for the appro- 
priate conversation, and the saved analysis state 

40 and ticket are preferably copied into the working 
areas pointed to by the globals (Ticket) and 
(Analysis Data). Then the procedure Re- 
plyAnalyzeText in the section camesage.c of the 
software described in the aforementioned GB-A- 

45 2,227,625 is called to check the request. If appro- 
priate, the analysis is initialized. This happens 
when text is deleted, for example, by an interrupt 
Any new text is added to the conversation and the 
C library procedure setjump of the aforementioned 

so software is called to store the current C context for 
the longjump return from parsing. This call to set- 
jump returns zero, and then the parsing routine 
parse of the aforementioned software is preferably 
called to analyze the conversation from the last 

55 saved state. When the parsing is terminated by 
reaching the end of the text currently held, the 
longjump call returns to the point at which setjump 
was called with a non zero reply, and the analysis 

12 
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is wrapped up by notifying the keystation 202, by 
way of example, of any change to the analysis. 
Preferably, the conversation analysis, such as ex- 
emplified by the software described in the afore- 
mentioned GB-A-2,227,625, always starts on the 
parse procedure. 

It should be noted, as described in the afore- 
mentioned GB-A-2,227,625, that preferably conver- 
sation analysis is performed on words or groups of 
symbols which are extracted by nextsym in section 
read.c of the conversation analysis software listing 
described in the aforementioned GB-A-2,227,625. 
Thus, until the conclusion of a stage of analysis, 
the symbols found are preferably stored in a buffer 
so that the analysis can backtrack if the current 
hypothesis proves incorrect, if a reanalysis is in 
progress, and there is such a queue of extracted 
symbols, nextsym preferably selects the next item 
in the queue. Otherwise, nextsym preferably reads 
a symbol from the text using the routine readsym 
described in the aforementioned software, which 
procedure preferably obtains characters from the 
text buffer using the routine readch. At this stage, 
fully replaceable synonyms, such as PLEASE and 
PLS, are merged to a single symbol code, held 
under the identifier (symbol). Other words are pref- 
erably allocated to a symbol such as S currency 
and individually identified by a number held in 
(symval). In the case of a currency identifier, this 
preferably identifies the actual currency, assuming 
that the conversation is being employed for foreign 
exchange. In addition, as was previously men- 
tioned, the preferred conversation analysis 
software-described in the aforementioned GB-A- 
2,227,625 includes an error detection procedure 
which checks the deals as they occur in real time, 
reporting erroneous or suspect conditions to the 
user based on analysis of the conversation, with 
the error messages preferably being placed below 
the insert line in the integrated screen display 238 
and the suspect flag data being highlighted in the 
summary analysis display area 266 on the inte- 
grated screen display 238 so as to provide an alert. 
It should be noted that in employing the conversa- 
tion analysis function in the system 200 the general 
display area 270 in the integrated screen display 
238 may be used to display additional financial 
information, such as a REUTER MONITOR page, 
prompt menus, analysis of the conversations, etc, 
with the analysis of the conversations normally 
preferably replacing the REUTER MONITOR dis- 
play. This area 270, may also be used for prompts 
and expanded analyses. With respect to the start- 
ing of conversations in the integrated system 200, 
such conversations can basically be started in 
three ways; namely, the user can contact another 
dealer, the user can accept the call from another 
dealer, or the user can enter the complete deal, 



using the CAPTURE function, as an offline deal. 
The particular menus displayed, preferably depend 
initially on how the conversation is started, with the 
person making the contact normally being referred 
5 to as the Market Taker and the person accepting 
the contact normally being referred to as the Mar- 
ket Maker. 

With respect to the printing of conversation 
tickets, assuming conversation analysis is em- 

70 ployed in the system 200, the conversation tickets 
are preferably created in the system 200 as the 
system extracts information by analyzing conversa- 
tions, with the display of the ticket being generated 
appearing on the integrated screen display 238. 

is Preferably, only one analysis can be associated 
with one conversation and, after a user confirms 
the analysis with respect to a current conversation, 
a ticket can be printed on the ticket printer 226 
depending on whether it is the Market Maker or the 

20 Market Taker, respectively, when the conversation 
is next terminated or printed. Preferably, the ticket 
printer 226 has the same characteristics as the 
conversation printer 230; namely, it accepts serial 
data and it prints on continuous paper. As a con- 

25 versation takes place, the associated conversation 
analysis area on the integrated screen display 238 
preferably shows a summary of the analysis in- 
formation which, if desired, can become a fully 
expanded version of a current analysis which is 

30 then displayed in the general display area 270. 
When the conversation is terminated and saved, 
preferably the analysis is saved with it Preferably, 
conversations and analyses are saved and deleted 
only as more storage is required. Before conversa- 

35 tion analysis can be confirmed, however, preferably 
it must contain at least the following information 
about the deal: the deal type, the deal direction, 
the currency or currencies, the amount, the rate or 
rates, and the value date. Thereafter, the user can 

40 confirm the conversation analysis by pressing the 
CONFIRM key on the keyboard 240. Once an 
analysis has been set into the confirming mode, 
the next time the conversation is ended on the 
dealers screen 238. a ticket is preferably printed 

45 and, thereafter, the conversation cannot be edited 
any further. If the analysis has not been confirmed, 
it can be marked as cancelled or wrong at any time 
during a real or offline conversation or when wrap- 
ping up a conversation by pressing the CANCEL or 

so WRONG keys on the keyboard 240. Thus, in order 
to generate a ticket on the ticket printer 226 asso- 
ciated with a video conversational negotiated trade, 
the conversation being analyzed is set to the CON- 
FIRMING state which ends the analysis. 

55 Although a more detailed description is includ- 
ed in EP and GB specifications, particularly EP-A- 
90305753, the automatic matching trade compo- 
nent will be briefly described with reference to 
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Figs. 7-9 and 30. In this regard, Fig. 7 corresponds 
to Fig. 1 of EP-A-90305753, with the matching 
communication network 220 corresponding to refer- 
ence numeral 22 in Rg. 1 of this publication, and 
with the central matching host computer 224 cor- 5 
responding to reference numeral 20 in Rg. 1 of this 
publication. In addition, the client sites in Rg. 7 
have been given reference numerals 210 and 212 
as opposed to the reference numerals 26a and 26b 
employed In Fig. 1 of this publication, since these w 
client sites 210, 212 contain the presently preferred 
integrated terminal controllers 214, 216, and with 
the keystations 24a and 24b of Rg. 1 of this 
publication being replaced by the presently pre- 
ferred integrated keystations 202, 204, 206, 208. 75 
Similarly, Rg. 8 corresponds to Fig. 2 of this pub- 
lication with the same exceptions, and Fig. 9 cor- 
responds to Rg. 3 of this publication with the same 
exceptions. Similarly, Rg. 30 corresponds to Rg. 6 
of this publication with the same exceptions with 20 
respect to the integrated keystations 202 and 206 
being substituted for keystations 24a and 24b, and 
with the reference numeral 224 being used for the 
central matching host computer 20 employed in 
Rg. 6 of this publication. As shown and preferred 25 
Rg. 8, the matching component for effecting auto- 
matic matching trades in the integrated trading 
system 200 is shown in which trading is effected 
through anonymous matching as opposed to 
through the previously described video conversa- 30 
tionai negotiated trades. Thus, in connection with 
the distributed matching communication network 
220 of the system 200, the matching host com- 
puter 224 serves as a computerised exchange in 
which its central role 15 to identify a buyer and 35 
seller who are willing to trade with one another 
based on specified criteria, such as price, quantity 
and credit. When such a matching event occurs, 
assuming the integrated keystation 202 has logged 
on to the matching communication network 220 in 40 
the manner previously described with reference to 
Rgs. 18-20, preferably the buyer and seller are 
informed of the trade and sufficient information is 
then provided to them through the respective in- 
tegrated terminal controllers 214 and 216 in order 45 
to complete the physical clearing of the transaction. 
As described in the aforementioned EP and GB 
specifications, in order to support this central func- 
tion, various support functions are required, one of 
which is preferably the maintenance of summary 50 
market information on the participant's keystation 
integrated display 238 at the various client sites 
210, 212. Preferably, at all times, those keystations 
202, 204, 206 and 208 which form part of the 
matching communication network 220 will display 55 
the best inside price for every instrument traded 
through that network 220. Although all four keysta- 
tions 202, 204, 206, 208 are represented as being 



part of the matching communication network 220, 
as well as being part of the conversation commu- 
nication network 218, this need not be the case. 
The best inside price is preferably defined to be 
the highest value bid and the lowest value offer in 
the network 220. Preferably, the prices are dis- 
played together on the integrated screen display 
238 with the quantity bid or offered at the specified 
price so that the trader at the respective integrated 
keystation 202, 204, 206 or 208 can observe the 
market activity. By observing the market activity, 
the trader can decide whether to enter a bid, or 
enter an offer into the market in an effort to com- 
plete a matching transaction, as opposed to the 
manner of openly negotiating a trade by exchang- 
ing discretionary messages through the conversa- 
tion communication network 218 to complete a 
video conversational negotiated trade. Thus, with 
respect to the client site 210 or 212 to the central 
matching host computer 224 will preferably result 
in one or more messages, represented by refer- 
ence numeral 32, going directly back as a directed 
message to the client site, 210 in this example, 
which initiated the transaction message. Another 
effect of the transaction message 30 being sent to 
the central matching host computer 224 is that for 
certain sorts of transactions, a broadcast message 
34 is generated by the central matching host com- 
puter 224 which is then delivered to all client sites 
210, 212 attached to the centra] matching host 
computer 224 via the matching communication net- 
work 222. Thus, the directed response or the di- 
rected message 32 only goes back to the particular 
client site 210 and, more particularly, the particular 
integrated keystation, 202 by way of example, at 
that client site 210 which initiated the transaction 
message, whereas the broadcast message, 34 
goes to all client sites 210, 212 and all the various 
integrated keystations 202, 204, 206, 208 asso- 
ciated at those client sites 210, 212 which are part 
of the matching communication network 220. As 
was previously mentioned, by way of example, in 
Rg. 7, a typical client site 210 is shown as having 
keystations 202 and 204, although the number of 
keystations available at a client site is merely limit- 
ed by the capacity of the system and the desired 
processing time. With respect to the distribution of 
the functionality in connection with the matching 
communication network 220 of the integrated trad- 
ing system 200, the matching communication net- 
work 222 preferably does not really play a part in 
that it is transparent to transactional information. By 
this what is meant is that when the transactional 
information leaves the client site 210, for example, 
it could be, if desired, encrypted or garbled in a 
way that the only other entity which could, under- 
stand it would be the central matching host com- 
puter 224 and that would be irrelevant to the func- 
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tion of the matching communication network 222 
since the network does not look at the messages, 
does not process the messages, and merely trans- 
fers these messages to the appropriate parts of the 
matching communication network 220, matching 
communication network 220, the system 200 es- 
sentially maintains a book of bids and offers in the 
matching host computer 224 and a user or keysta- 
tion 202, 206, by way of example, and a client site, 
such as client sites 210 and 212, respectively, 
interacts with the book by submitting bid, offer, hit, 
or take transactions, such as illustrated in Fig. 8. 
The order entry function is preferably convention- 
ally achieved through data entry using the inte- 
grated keyboard 240, the mouse 242, or any other 
conventional data entry tool. The matching host 
computer 224 validates the transaction request, 
processes the bid, or the hit or take, according to 
the rules of the market, and attempts to find match- 
es between this new entry and the other bids or 
offers posted in the matching communication net- 
work 220 book. If a match is found, then the trade 
is automatically executed, the participants to the 
trade are informed, al! databases and trader 
screens 238 are updated as to the quantities traded 
and the quantities remaining and, if desired, a 
clearing agency may be informed as to the details 
of the trade so that payment and exchanges may 
be completed. If on the other hand, a match can 
not be found, then the matching communication 
network 220 preferably either disposes of the entry 
for hit or take or keeps the entry for bid or offer for 
later processing. Preferably, in all cases, transac- 
tions are processed to completion according to 
certain rules and the various client sites 210, 212 
preferably receive real time updates of the new 
status of the trading instruments, assuming that 
they are members of the matching communication 
network 220. Thus, as shown and preferred in Fig. 
8, the client site systems 210, 212, only two of 
which are shown by way of example in Fig. 8, 
when the associated keystations 202, 204, 206, 208 
have selected the matching trade option, submit 
transactions, such as represented by reference nu- 
meral 30 in Fig. 7, to the central matching host 224 
via the matching communication network 222. 

As will be explained in greater detail hereinafter 
with reference to Fig. 30, the submission of a 
transaction 30 from a 



such as to the matching host computer 224. In this 
regard, the network 220 is functioning similar to a 
paired cable in that it is there to pass the informa- 
tion back and forth. Of course, the network 220 has 
various other-communication functions which, how- 
ever, for purposes of understanding the matching 



component of the integrated system 200, are un- 
necessary to go into. Suffice it to say that prefer- 
ably the matching communication network 220 
uses a protocol which can be termed hierarchal 

5 fan-out in which one node transmits to multiple 
nodes which in turn transmit to multiple other 
nodes. Thus, matching communication network 220 
helps implement broadcast capabilities integrated 
with a message switching network to achieve full 

to tolerance in broadcast distribution. It should be 
noted, when a match occurs, the central matching 
host computer 224 will preferably send directed 
messages or responses to all of those parties in 
the system 200 that were involved in the match, so 

75 that, in some instances 2,3 or more client sites 
210, 212 may be involved in receiving the directed 
message. However, this still differs from the broad- 
cast message which is sent to all client sites ir- 
respective of their involvement in a particular 

20 match. 

Referring now to Fig. 8, this figure illustrates a 
typical data flow in the integrated system 200, for 
the entry of a bid or entry of an offer, with the 
matching communication network 220, as was pre- 

25 viously mentioned, being transparent to transac- 
tional information Integrated keystation 202, by way 
of example, submits a bid transaction to the central 
matching host computer 224 through the matching 
communication network 220, via the terminal com- 

30 puter 250 and the concentrator computer 254. The 
directed message or directed response 32 which it 
receives back from the central matching host com- 
puter 224 is termed a bid acknowledgment or BID- 
ACK. This acknowledgment is a command ac- 

35 knowledgment which is preferably followed by an 
entry position message and is, as previously men- 
tioned, directed directly back to the keystation 202 
via the concentrator computer 254, the local area 
network 256, and the terminal computer 250. In 

40 addition, as shown and preferred in Fig. 8, a bid 
update message is broadcast by the central match- 
ing host computer 224 to all keystations 202, 204, 
206, 208 in the system 200 which have logged on 
to the matching communication network 220, such 

45 as represented by reference numeral 34a in Rg. 8. 
This broadcast message 34a preferably occurs if 
this new bid 32a was a new best bid in the system 
200 with respect to the matching component, or 
was an additional quantity being bid at the best 

50 price in the system 200 with respect to the match- 
ing component. Thus, if this new bid 32a is at the 
highest price or better or higher, then it will result 
in a bid update broadcast message 34a going out 
throughout the system 200 to all keystations which 

55. have logged on to the matching communication 
network 220. in addition, as also shown by way of 
example in Fig. 8, if it is desired to disseminate an 
external ticker 60, then the ticker information 60 will 
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also be provided of the best bid or best offer. 
Preferably, the same procedure is followed with 
respect to entry of an offer with the messages, in 
this instance, being identified as offer, given refer- 
ence numeral 51, offer acknowledgment or OFFER- 
ACK, given reference number 32b, and the broad- 
cast message for offer update, being given refer- 
ence numeral 34b. 

Referring now to Rg. 9, the data flow in the 
integrated system 200, is illustrated with respect to 
a situation in which there was a hit bid resulting in 
a trade. In this situation, there is substantially more 
activity than the situation previously described with 
reference to Fig. 8. Thus, as shown and preferred 
in Fig. 9, if the integrated keystation 206 submits a 
transaction called "hit bid", represented by refer- 
ence numeral 62, to the central matching host 
computer 224 via the matching communication net- 
work 220, a hit acknowledgment or HIT/ACK, repre- 
sented by reference numeral 64, is provided back 
to keystation 206 as a directed message. At that 
point, the central matching host computer 224 will 
recognize that a match is possible because the "hit 
bid" message says that keystation 206 is willing to 
trade at the bid price. Assuming that credit is OK 
and does not play a role beyond that in this trans- 
action, the central matching host computer 224 
determines that a match is possible but, preferably, 
before committing to the match, it may get in- 
volved in a risk limiting protocol using a transaction 
desk 70, as described in the aforementioned EP 
and GB specifications which determines whether 
the trade is possible, and if so, acknowledges this 
to the central matching host computer 224. Assum- 
ing that a trade is possible, then a match occurs. At 
that point several messages are generated from the 
central matching host computer 224 through the 
matching communication network 220. One of 
these messages is termed the match message, 
given reference numeral 65, which is a directed 
message that goes to the bidder, which in this 
instance is keystation 206, and to the keystation 
202, which originally owned the bid. Thus, in this 
instance directed messages go to more than one 
integrated keystation 202, 206 logged on to the 
matching communication network 220. Preferably, 
every match must be acknowledged so there is a 
match acknowledgment message, MATCH-ACK 
which comes back from the buyer and seller 
keystations 202 and 206 and is used to determine 
that the match was in fact received correctly and 
that the deal can be considered complete at that 
point. The response of the integrated terminal con- 
troller 214, 216 to such a match notification has 
been previously discussed with reference to Fig. 25 
which represents software resident in the various 
terminal computers 250 associated with the keysta- 
tions and in the integrated terminal controllers 214, 



216, themselves, in the respective data servers 
262, as a result of conventional programming. In 
addition, a broadcast message is generated that a 
trade has occurred which trade update message, 

5 given reference numeral 67, may possibly cause a 
new best bid to occur or could affect the quantity 
or price at the top of the book. Again, if the trades 
and best bids go into the ticker 60, then this 
information is provided to the ticker as well. Simi- 

10 larly, if clearing information is provided to a clear- 
ing house, this too occurs as represented by refer- 
ence numeral 69. In addition, as shown and pre- 
ferred , trade tickets may also be generated, such 
as previously referred to with reference to Fig. 26. 

75 Thus, trade ticket information is also preferably 
provided to the participating integrated keystations 
202, 206 in the above example, so that the trade 
tickets can be generated with respect to the match- 
ing trades. 

20 It should be noted that the concentrator com- 
puter 254, which interfaces with the matching com- 
munication network 220, preferably always commu- 
nicates with the associated conversation server 252 
containing the database server 262 which controls 

25 the ticket generation, via the keystation terminal 
computer 250. Thus, the concentrator computer 
254 and the conversation server 252 are tied to- 
gether in the integrated terminal controller 214, 216 
through the local area network 256 and the asso- 

30 ciated keystation terminal computers 250. Conse- 
quently, the software associated with the "ticket 
received" function illustrated in Rg. 26, which may 
be accomplished by conventional programming, is 
resident in the terminal computers 250 associated 

35 with the individual keystations and in the data serv- 
er 262 portion of the conversation server 252 in the 
integrated terminal controller 214, 216. 

With respect to the details of the various books 
employed in the distributed matching component of 

40 the integrated trading system 200, these details are 
described in the aforementioned EP and GB speci- 
fications. Suffice it to say that the central matching 
host computer 224 maintains a host book database 
comprising all of the active bids and offers in the 

45 integrated trading system 200 which have been 
provided by keystations which have logged on to 
the matching communication network 220 and that 
each of the respective integrated keystations 
logged on to the matching communication network 

so 220 has an associated local data base keystation 
book which comprises a subset of the host book, 
with the content of each of the keystation books 
having an associated display depth range control- 
lable by the central matching host computer 224 

55 and being updatable by transaction update broad- 
cast messages received from the matching host 
computer 224 through the matching communication 
network 220. In this regard, reference is made to 
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Fig. 30 which illustrates the two collections of in- 
formation which are being maintained at the client 
sites 210, 212 which have logged on to the match- 
ing communication network 220. As shown by way 
of example in Fig. 30, one of these collections of 
information is the book for each instrument which is 
maintained at the keystation sites, 202 and 206, in 
the above example, and have been given reference 
numerals 112 and 110 respectively in Fig. 30. 
Another book maintained at each site is a local 
entry data base or order book which has been 
given reference numerals 116 and 114, respec- 
tively, in Fig. 30. As previously mentioned, there is 
also the host or system book data base associated 
with the central matching host computer 224 which 
has been given reference numeral 118 in Fig. 30. 
Each time a client site 210 or 212, by way of 
example, starts up as an integrated keystation log- 
ging on to the matching communication network 
220, such as by using the log on software and 
procedure illustrated by way of example in Figs. 18 
- 20 and in Table A annexed hereto as an Appen- 
dix, which is written in C language for use with an 
80386 computer, and which is resident in the termi- 
nal computer 250 of the integrated keystation, the 
integrated keystation which is logging on to the 
system 200 is preferably initially empty and re- 
quests download of the currently active books from 
the matching host computer 224. Preferably, sepa- 
rate books are maintained for each trading instru- 
ment, and each of these books is maintained at a 
given display depth. In this regard, it should be 
noted that an update broadcast message is prefer- 
ably only broadcast when the price information is 
inside the assigned display depth that has been 
assigned by the matching host computer 224. With 
respect to the local entry database or order books 
114, 116, these order books 114, 116 are prefer- 
ably updated by directed messages from the 
matching host computer 224 and/or record the 
orders of the particular integrated keystation 202, 
206, by way of example, which had been sent to 
the matching host computer 224 through the 
matching communication network 220. In this re- 
gard, these order books 114, 116 are preferably 
kept current so that there is a listing only of orders 
which are still present in the central matching host 
computer 224 from the respective integrated 
keystations 202 or 204, by way of example. 

This order database 114 and 116 gets modi- 
fied, such as through the removal of data, due to 
various occurrences, such as when a complete 
match has occurred for a given order and an entry 
remove message is provided, or if it is a partial 
match you may get an entry message that tells you 
that only a partial match has been done against 
that order. The match notification, which was pre- 
viously referred to, preferably refers to a particular 



order that is contained in the order database 114 or 
116 and indicates what quantity or portion of the 
order has been matched. If all of the order has 
been matched, the entire order is then preferably 

5 deleted from the respective order database 114 or 
1 1 6. By way of example, if a bid were put in for ten 
million yen at a price of 127 and the display was 
enabled, that is the display depth was set to some- 
thing greater than or equal to one, then the central 

to matching host computer 224 would preferably con- 
struct a broadcast message, which is the afore- 
mentioned update broadcast message, which 
would inform all client sites 210,212 that a new bid 
had been added to the Yen book, assuming that 

75 were the instrument being traded. The update mes- 
sage would instruct an operation block which would 
say add to index one the ten million at 127. As for 
the other parameters in the update message, add 
index would equal one, type would equal bid, quote 

20 would equal 127, and quantity would equal ten 
million at 127. As for the other parameters in the 
update message, add index would equal one, type 
would equal bid, quote would equal 127 and quan- 
tity would equal ten million. In the above example. 

25 the transaction achieves two functions. The first 
function it achieves is that a bid is submitted and 
the matching host computer 224 responds to the 
integrated keystation 202 submitting the bid that 
the bid was accepted and that there was no am- 

30 biguity in that the bid is definitely in the system 
200; the system 200, namely the matching host 
computer 224, has it; and the local entry database 
116 has it The other function indicates that the bid 
was of a certain characteristic that the rest of the 

35 "matching trading world" in the system 200 should 
know about, and this is accomplished as a result of 
the broadcast message which was generated to all 
of the client sites 210, 212 logged onto the match- 
ing network 220, which were then told about this in 

40 summary as opposed to being given all of the 
detailed information. It should be noted that, as 
previously mentioned, in terms of functional opera- 
tion, the entry of a bid to the system is the same 
as entry of an offer. 

45 In the situation when a trade occurs, this 
means that a matching offer is present in the 
system, the matching host computer 224 has ac- 
cepted that matching offer, and sends back the 
acknowledgment command, in effect retrieving the 

so existing book on Yen, in the above example, finds 
out that there is ten million yen at 127 in the book, 
adds to that the newly entered fifteen million at 
127, and is aware that it has positioned fifteen 
million at 127. The matching host computer 224 

55 then does the match up including that ten million 
and does the trade, taking out the existing bid, so it 
reduces that amount to zero million at 127 leaving 
over five million at 127 on the offer side. In this 
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instance, as will be further explained with reference 
to Fig. 30, at least two directed messages have 
been sent, actually four having been transmitted to 
the client sites 210,212 that are involved in the 
trade. The seller will get an indication that his Yen 
bid has traded by means of a match notification 
and he will, thereafter, be informed who the coun- 
terparty was after the match has been made. The 
clearing and settlement of the trade will then pref- 
erably be the responsibility of the subscribers. The 
counterparty who originally transmitted the offer 
and entry position message saying that it had a 
Yen offer positioned greater than the bid will then 
get an entry positioned yen offer at five million at 
127 and will get a match notification saying that, 
with respect to his offer, ten million of his original 
fifteen million has traded with the party who will 
then be identified. Lastly, the update broadcast 
message will be constructed and broadcast to all 
client sites 210, 212 logged on to the matching 
network 220 to update the trading book. That up- 
date message will preferably, in the above exam- 
ple, contain two operation blocks, one which will 
remove the bid information from the client book 
and the second which will post the new five million 
offer which remains on the offer side and will show 
that a trade took place. In addition, as was pre- 
viously mentioned, if desired, ticker information will 
also be provided in the update message saying 
what traded, keeping track of the cummulative vol- 
ume, the net change, the number of changes, the 
high limits, the low limits and so forth. It should be 
noted that preferably only the integrated keystation 
that either executed the transaction, for example 
keystation 202, or was involved somehow in that 
transaction will receive the directed message with 
respect thereto and not other integrated keysta- 
tions, such as keystation 204, at the same client 
site 210, whereas with respect to broadcast mes- 
sages all integrated keystations logged on to the 
matching network 220 at all client sites receive 
these messages. If desired, with respect to credit, 
this can be controlled on a client site by client site 
basis as opposed to a keystation basis. Thus, in 
the system 200, the matching communication net- 
work 220 has two functions, one of which is di- 
rected message delivery and the other of which is 
broadcast message delivery. 

Referring now to Fig. 30 in greater detail, the 
matching communication network 220 which, as 
was previously mentioned, is transparent to trans- 
actional information, has been omitted for purposes 
of explanation of the message flow in the system in 
accordance with the method of the present inven- 
tion. For purposes of the example of Fig. 30, in- 
tegrated keystation 202 can represent any keysta- 
tion which originates a transaction and integrated 
keystation 206 can represent any keystations which 



are involved as counterparties in the transaction 
which, as was previously mentioned can be more 
than one keystation at more than one location. The 
keystations 202 and 206 are normally remotely 

5 located from each other such as, for example, 
keystation 202 being at a client site 210 in New 
York and keystation 206 being at a client site 212 
in London, which are the same locations used in 
the example of Fig. 4 relating to the transaction of 

w video conversational negotiated trades, although 
the locations need not be the same. 

In addition, the keystations 202 and 206 are 
remotely located from the central matching host 
computer 224. In order to understand the message 

is flow illustrated in Fig. 30, we will assume that the 
originating keystation 202 is receiving a display of 
the keystation book database located at keystation 
202 on its integrated screen display 238. Assuming 
that the operator at the integrated keystation 202 

20 then desires to enter a bid or an offer, either of 
which will be termed an order, this information is 
input to the keystation 202 via conventional means, 
such as the integrated keyboard 240 or a mouse 
242, by way of example. The keystation 202 then 

25 preferably validates the order and maintains its 
local order data base or local entry data base 1 1 6. 
The order, instead of being a bid or an offer, could 
be a hit or a take for a particular trading instrument 
as well since all of these various items would 

30 constitute an entry of an order. After the order has 
been entered, validated, and, the order data base 
116 maintained, a transaction message is built and 
sent as a directed message to the central matching 
host computer 224 through the matching commu- 

35 nication network 220. This is represented by refer- 
ence numeral 120 in Fig. 30. This transaction mes- 
sage 120 is received by the central matching host 
computer 224 and contains transaction information. 
At this point, preferably the central matching host 

40 computer 224 sends back a directed message, 
termed a command acknowledgment message and 
given reference numeral 122, to inform integrated 
keystation 202 that the transaction message 120 
has been received. The transaction message 120 is 

45 time-stamped by the central matching host com- 
puter 224 at this point. Preferably the display 238 
of keystation 202 will indicate "please wait" until 
the transaction message 120 has been acknowl- 
edged. Preferably, such acknowledgment happens 

so relatively quickly, such as in about two seconds, by 
way of example. The central matching host com- 
puter 224 then preferably processes the transaction 
message 120 against the central matching host 
computer 224 stored copy of the system or host 

55 book which is contained in the host book data base 
118. At this point, the central matching host com- 
puter 224 preferably either adds the entry of the 
transaction or the order from integrated keystation 
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202 to the host book data base 118 or matches 
that entry against existing bids and offers contained 
in the host book data base 118. Once that process- 
ing is completed, the central matching host com- 
puter 224 is ready to generate output messages 
not only to the originating keystation 202, but pos- 
sibly to other keystations, such as the counterparty 
keystations represented by 206 and, assuming that 
an update message is required, to all keystations 
which have logged on to the matching communica- 
tion network 220. Thus, matching host computer 
224 generates directed messages back to each of 
the keystations involved in the matching transac- 
tion, such as the originating keystation 202, andl 
assuming that there is a match, keystation 206 as 
the counterparty keystation, and generates the up- 
date broadcast message to all keystations logged 
on to the matching network 220. It should be noted 
that, as previously mentioned, a single transaction 
message 120 from keystation 202, whether it is a 
hit, or a take, or a bid, by way of example, could 
result in multiple matches. For example, if keysta- 
tion 202 wants to hit the bid for a quantity of 20, it 
is possible that to satisfy that order more than one 
match couid be involved such, as for example, four 
or five different matches, particularly, since the 
keystation book at keystation 202 merely displays 
accumulated summaries of the bids or offers. 

If multiple matches occur, then, thereafter, the 
identity of all of the counterparties involved in the 
multiple matches are displayed on the integrated 
screen display 238 of the originating keystation 202 
for settlement purposes. Thus, on any given trans- 
action, there will always be directed messages 
involving the transaction originator and involving 
one or more counterparties or affected parties in 
that trade or transaction. If the market is an auction 
market, then it preferably has a price depth of one 
so that this determines how many prices the cen- 
tral matching host computer 224 can maintain with 
only one price being maintained in an auction 
market. When a new bid goes in which betters the 
existing bid in an auction market, the existing bid is 
actually removed and effectively cancelled in the 
book. Preferably, after all of the directed messages 
are generated to the counterparties, and the asso- 
ciated directed message acknowledgments, such 
as represented by reference numerals 124. 126. 
128 and 130 in Fig. 30, the update broadcast 
message, represented by reference numeral 132 in 
Fig. 30, is sent to all keystations logged on to the 
matching network 220 regardless of whether or not 
they were involved in their particular matching 
transaction. It should be noted that preferably the 
first six steps illustrated in Fig. 30 with respect to 
the central matching computer 221 are all essen- 
tially asynchronous to any outside events. When 
the keystations 202 and 206 receive the update 



broadcast message, it will be processed against 
the local keystation book database 110, 112 and 
the local copy of the book will be maintained. As 
was previously mentioned, it should be noted that 

5 this local keystation book 110, 112 is not an exact 
carbon copy of the central system book 118, but 
rather is only a selected subset of it which com- 
prises an accumulated summary of bids and offers 
within the assigned display depth. Thus, preferably, 

w Fig. 30 illustrates a generic template for the pro- 
cessing of messages throughout the integrated 
trading system 200 in accordance with the method 
of the present invention in order to provide the 
distributed functionality of the system to keysta- 

75 tions logged on to the matching network 220. 

It should be noted that the concept of originat- 
ing keystation and counterparty keystation moves 
around with each transaction so that for each trans- 
action the originator may be different and may, for 

20 different transactions occurring at the same time, 
be an originating keystation in one instance and a 
counterparty keystation in another instance, in ad- 
dition, there are other instances in which the 
keystation may merely be a bystander and not 

25 involved in the particular transaction at all. Prefer- 
ably the control of the overall distributed matching 
system is maintained by the central matching host 
computer 224 which operates in accordance with a 
set of rules which govern how the transactions are 

30 processed. Preferably, the central matching host 
computer 224 processes transactions against a 
particular trading instrument in time order of entry 
into the system. In this regard it should be noted 
that it is not time entry of orders per se but time 

35 entry of orders related to a particular trading book 
or trading instrument. Thus, there would be time 
order entry assigned to Yen, a different time order 
entry consideration assigned to Deutsch Marks, 
and so forth if the trading instruments were foreign 

40 exchange currencies. 

In Figs 31-34, which correspond to Figs. 4-6 
and 8 of GB-A-2,224 ( 141, the trading ticket output 
is shown. Pressign the TICKET key on the in- 
tegrated keyboard 240 causes the expanded anaiy- 

45 sis display mode to be entered or stored in the 
data base server 262. As was previously men- 
tioned, in this mode, the expanded analysis for the 
current conversation, assuming the keystation is 
connected to the conversation communication net- 
so work 218, is displayed on the screen 238. The 
expanded analysis preferably shows the full con- 
tents of all the fields that can appear in the analysis 
except that payment instructions may, if necessary, 
be truncated. In the case of forward deals, prefer- 

55 ably the information for both value dates is shown, 
requiring four transactions. While in expanded ana- 
lysis display mode, the expanded analysis on dis- 
play is preferably kept up-to-date with the con- 
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versation. Swapping between two conversations 
would automatically preferably swap between the 
two expanded analyses so that the one for the 
current conversation was always visible. The ex- 
panded analysis display mode preferably remains 
in effect until a different use of this display area on 
the screen 238 is requested. Preferably, rf a print- 
out of the conversation analysis is requested, the 
output on the conversation printer 230 is similar to 
that of the displayed window, although the payment 
instructions may be moved to a separate line if 
desired. With respect to printing a conversational 
ticket with the ticket printer 226, the format of the 
ticket is preferably similar to the expanded analysis 
such as the conversational trading ticket illustrated 
in Fig. 17, however the order of the information 
may be changed to present the more critical in- 
formation first. Of course, although the creation and 
storage of a ticket has been described in terms of 
real time conversation analysis, such a system is 
not necessary for the generation of tickets per se 
which merely requires a local data base storage of 
trading tickets no matter how these trading tickets 
are dynamically created, with the data base server 
262 providing such a local data base storage, by 
way of example, in the integrated terminal control- 
ler 214, 216 for both conversational trading tickets 
and match tickets, with the match tickets being 
stored as pseudo conversation, such as illustrated 
in Fig. 16, by way of example. 

For purposes of better understanding the pre- 
ferred ticket output feed 234, 236, the preferred 
ticket output protocol and process will now be 
described for handling the transfer of trading ticket 
information between the local data base server 262 
and the back office computer. In this regard, with 
reference to U.S. Patent No. 4,745,559 incorpo- 
rated by reference herein, the local data base serv- 
er 262 is analogous to the local data base de- 
scribed in U.S. Patent No. 4,745,559, except as 
will be described in greater detail hereinafter, with 
respect to the various differences as it relates to 
the presently preferred ticket output protocol and 
process employed in the system 200. Although, the 
preferred ticket output protocol preferably em- 
ployed in the system 200 preferably employs field 
identifiers or FIDs which are analogous to the field 
identifiers referred to in the aforementioned U.S. 
Patent No. 4,745,559, the information contained 
therein is totally different. In place of the record 
identifier codes or RICs referred to in the afore- 
mentioned U.S. Patent No. 4,745,559, the ticket 
output protocol process preferably employs unique 
deal identifiers which correspond to the ticket num- 
ber on the printed deal ticket as well as to the 
integrated terminal controller 214,216 which con- 
tains the local data base server 262 containing that 
record. Thus, the deal or trading ticket identifier 



includes the terminal controller identifier as well as 
a ticket number, with deals preferably being given 
sequential numbers in order of their confirmation. 
The sequence is preferably in the range of 1 - 

5 999999, by way of example, for each terminal 
controller 214,216. The deal identifier preferably 
starts with the terminal controller identifier and a # 
and is followed by the sequential number, such as, 
for example, AAAA#1 23456 for deal number 

10 123456 on terminal controller AAAA. In addition to 
retrieving the deal per se, the status of the data in 
the terminal controller system can also preferably 
be retrieved using the terminal controller identifier 
AAAA#INFO, by way of example. 

75 Preferably, as will be described in greater de- 

tail hereinafter, the data base server 262 can sup- 
ply two kinds of data to be retrieved about the 
deals being conducted by the keystations asso- 
ciated with that terminal controller 214, 216; name- 

20 ly information on a deal, and status information on 
what is stored in the data base. As will be de- 
scribed in greater detail hereinafter, it is the up- 
dates from the status record which are preferably 
looked at to see if there is a change in status 

25 indicating that a new trade has arrived, which per- 
mits rapid transfer of trading information, such as 
the trading tickets, without the need for continuous 
polling of the various terminal controllers 214,216. 
It should be noted that each terminal controller 

30 214,216 keeps its own unique record o£ deals and 
has its own unique set of deal identifiers which are 
independent of the other terminal controllers 214, 
216 associated with the back office computer, as- 
suming more than one terminal controller is asso- 

35 ciated therewith, since a portion of the record iden- 
tifier is the unique identification of the terminal 
controller 214, 216 itself. A data record associated 
with a terminal controller identifier or TCID, is pref- 
erably a collection of data items with each data 

40 item being assigned a unique Held Identifier Num- 
ber or FID. The presently preferred ticket output 
protocol employed in the system 200 in accor- 
dance with the method of the present invention 
preferably uses the FID number to identify each 

45 data item within a message. Preferably, records in 
the system are grouped into classes, such as for a 
deposit deal, or a swap deal or a single deal, such 
as a spot or outright deal, with each class prefer- 
ably relating to a set of FIDs called a Field List 

so The Field List is analogous to a template except 
that it relates to the format of the transmission of 
the data as opposed to the display per se, with the 
Field List defining which collectiori~of "data items 
will be received for that class of record. This Field 

55 List is preferably contained in the record response 
of the data base server 262 to the request of the 
back office computer for trading ticket information. 
Since single deals such as spot or outright 
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deals; swap deals; and deposit deals have certain 
characteristics unique from each other, unique field 
identifiers must preferably be provided to distin- 
guish these types of deals in the preferred ticket 
output protocol. 

Preferably, requests for the status of the deal 
or trading ticket data base contained in the local 
data base server 262 of a particular terminal con- 
troller 214, 216 will provide information to the back 
office computer on the earliest and latest deal 
identifiers stored at the local data base server 262, 
with the date and time of the trading tickets. This 
information would permit the back office computer 
to determine the range of trading tickets available 
for retrieval. 

Preferably, all fields within the messages trans- 
mitted between the local data base server 262 and 
the back office computer contain ASCII characters 
which makes them suitable for display on a video 
terminal with little or no additional formatting, thus 
making this data feed ideal for quick implementa- 
tion in a data display system, such as via the 
integrated screen display 238. 

Fig. 31 diagrammaticaliy illustrates the various 
portions of the trading ticket output system con- 
cerned with the presently preferred trading ticket 
output protocol of the system 200. Thus, a conven- 
tional serial line handler provided by the operating 
system is employed with, for convenience of ex- 
planation, the input and output being separately 
illustrated as the input handler 800 and the output 
handler 802. The input process 804 preferably ex- 
tracts input bytes from the serial line via the input 
handier 800 and places the: in an input buffer 806. 
The input buffer 806 performs the checks for input 
packets and checksums and can also set flags to 
ask the ticket output process 808 to generate the 
control characters ACKNOWLEDGE and NO AC- 
KNOWLEDGE at appropriate points in the output 
stream. The input process 804 also preferably de- 
tects these control characters, such as ACKNOWL- 
EDGE and NO ACKNOWLEDGE, at the appropriate 
points in the input stream, with the occurrence of 
these control characters being tested for by the 
ticket output process 808 when it has sent a mes- 
sage. The ticket output process 808 is preferably 
scheduled regularly and has several independent 
tasks, the main ones of which are preferably taking 
confirmed bytes from the input buffer 806 and 
placing them in a message buffer 810, scanning 
the message 810 to find the next complete mes- 
sage if available and, when found, checking the 
message. If the message is faulty, an appropriate 
error response is sent to the output message buffer 
812. If, however, the message is valid, appropriate 
flags are set to request the required action. Prefer- 
ably, no further messages are then handled by the 
ticket output process 808 until the action is com- 



plete. If a ticket or status report is requested by an 
input message, then the ticket output process 808 
preferably gathers the data from the ticket data 
base 814 and places it in the defined format, 

5 determined by the Field List, in the output mes- 
sage buffer 812. When a message has been as- 
sembled in the output message buffer 812, the 
ticket output process 808 preferably adds the ap- 
propriate control bytes and transfers it to the output 

to handler 802, passing as many characters as the 
output handler 802 can accept at a time until the 
whole message has been transferred to the back 
office computer from the local data base server 
262. The ticket data-base process 814 is preferably 

75 modified to support updates of the status data in 
the ticket output protocol. The addition is prefer- 
ably required when the data base is modified by 
the addition of a new trading ticket or the removal 
of an old ticket. In these cases, the ticket data base 

20 process 816 preferably sets a flag so that the 
update will be created by the ticket output process 
808, with the flag being cleared, as appropriate, by 
the ticket output process 808. The ticket data-base 
process 816 is preferably designed so that it adds 

25 a ticket to the end of the data base 814 and 
obtains space as necessary by removing the earli- 
est tickets from the beginning of the data base 814. 
Either of those changes alters the status of the data 
base 814 so that when there is a status check by 

30 the back office computer, the back office computer 
is, thus, advised of the addition of a trading ticket 
by detecting the change in status. This is indicated 
to the ticket output process 808 by setting out a 
flag which is cleared, when appropriate, by the 

35 ticket output process 808. 

Fig. 32 further illustrates the presently pre- 
ferred operation of the ticket output process 808 
which, as can be seen, is entered at frequent 
intervals. The logic preferably gives priority to re- 

40 sponses to requests, and handles one request at a 
time. A request preferably remains in the input 
message and analysis stage 810 until it has been 
answered. When any message has been created 
for output, preferably the ticket output process 808 

45 is dedicated to the output of the message until it 
has been ACKNOWLEDGED or has been transmit- 
ted a given number of times without acknowledg- 
ment. Preferably, when no message is being out- 
put, the ticket output process 808 checks to see if 

so an input message has requested a trading ticket. Is 
so, the trading ticket is retrieved, a message is 
created according to the type of ticket by use of 
the Field List, and the new message is marked for 
output to the back office computer. When no ticket 

55 is being requested, the ticket output process 808 
preferably checks if the status record has been 
requested. If so, the status data is preferably ob- 
tained and the status record is set up for output in 
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a similar way to the trading ticket output. If, how- 
ever, no status is requested, then the ticket output 
process 808 preferably checks to see if the status 
has been marked as changed by the ticket data 
base process 816. If a change is detected, the flag 
indicating the change is preferably cleared. The 
logic then preferably checks if the status record is 
currently requested in an updating mode. If this 
has occurred, the new status is preferably output 
on the line and the ticket output process 808 cre- 
ates a new status in the output message buffer 81 2 
and then arranges that it will output the message. 
In the aforementioned implementation, the status 
record is preferably updated by retransmission of 
the whole status record. If none of the above con- 
ditions exist, the ticket output process 808 then 
preferably tries to find a complete new input mes- 
sage. If this succeeds, the ticket output process 
808 preferably analyzes the input message. A valid 
message causes a change in the analysis data. 
The analysis of a valid message requesting data 
sets flags which then cause the ticket output pro- 
cess 808 to generate the requested output as it is 
rescheduled repeatedly. Other valid messages just 
change the current state of the analysis data, 
whereas invalid messages cause the ticket output 
process 808 to generate an appropriate error re- 
sponse. The above described procedure is illus- 
trated in the flow diagram of Fig. 32. 

Referring now to Rg. 33 the operation of the 
terminal controller data base server 262 when a 
new trading ticket has been generated is shown. 
Thus, when a new deal is generated, as repre- 
sented by reference numeral 850, the trading ticket 
corresponding to the deal is added to the list of 
deals, with allocations of the deals or tickets being 
in numerical order as was previously described, 
such as represented by reference numeral 852. 
The status record is then updated, giving the last 
deal number, as represented by reference numeral 
854, and a determination is made as to whether the 
deal status is being retrieved with an update, as 
represented by reference numeral 856. If the deal 
status is being retrieved with an update, the update 
is sent to the back office computer to update the 
status record, such as represented by reference 
numeral 858. and if it is not, then the routine ends, 
as represented by reference numeral 860. 

Referring now to Fig. 34, a flow chart is shown 
of the operation of the local data base server 262, 
with respect to requests for tickets received by the 
local data base server 262 from the back office 
computer. Thus, the trading ticket requested by the 
back office computer is requested by Deal Iden- 
tifier, which, as previously mentioned, does not 
specify the type of deal. This is represented by 
reference numeral 900. The type of deal indicated 
is then looked at in the ticket record being re- 



trieved, as represented by reference numeral 902, 
and the ticket output message is then formatted 
using the Field List specific to the type of deal, as 
represented by reference numeral 904 in Fig. 34. 

5 The formatted record response message, which 
now contains information as to the type of deal, as 
well as the various parameters and values asso- 
ciated with them, is then sent to the back office 
computer in the appropriate deal format, based on 

70 the Field List contained in the retrieved record and, 
for the first time, the back office computer finds out 
what type of deal was involved with the request. 
This is represented by reference numeral 906. It 
should be noted, as previously mentioned, the re- 

15 quest by the back office computer and the re- 
sponse to the back office computer from the local 
database server 262, contain a "Tag" which iden- 
tifies the particular request being made. 

Thus, by employing the integrated trading 

20 method of the present invention, the speed and 
reliability of both automatic matching and negoti- 
ated video conversational trades may be combined 
in a single system to provide individual subscribers 
with maximum flexibility and optimal efficiency to 

25 effectuate and complete the type of trade demand- 
ed by the time and circumstances available, and to 
generate a ticket corresponding to the trade, ir- 
respective of the type of trade transacted. 

In the first aspect of the invention as defined 

30 by Claim 1, the system may further comprise a 
second interface means connectably disposed be- 
tween at least one of said keystation means in said 
second plurality of keystation means and said first 
communication means for selectively interfacing 

35 said one of said keystation means in said second 
plurality of keystation means with said first commu- 
nication means, said one of said keystation means 
in said second plurality of keystation means com- 
prising video display means capable of displaying 

40 both said bids and said offers. The common data 
input means may further comprise means for tog- 
gling between said matching trades and said video 
conversational negotiated trades for selectively ef- 
fectuating said trades via said one of said keysta- 

45 tion means in said second plurality of keystation 
means. On of the keystation means in said second 
plurality of keystation means further comprises 
means for selectively varying the content of the 
display on said common video display means in 

so response to said toggling of said data input means. 

In the first aspect of the invention as set out in 
Claim 1, the keystation means may comprise a 
computer means. Whether it does or not, the inter- 
face means may comprise a conversation server 

55 means for interfacing said video conversational tex- 
tual data messages with said first communication 
means. Whether it does or not, the interface means 
may comprise a concentrator computer means for 
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interfacing said bids and said offers with said first 
communication means. When the keystation means 
does comprise a computer means, the data input 
means may further comprise means for periodically 
providing a keep alive signal to said keystation 
computer means, said keystation computer means 
comprising means responsive to said periodically 
provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said keystation means associated with a given 
data input means when said keep alive signal pe- 
riodically provided from said associated data input 
means is not provided. The means responsive to 
said periodically provided keep alive signal may 
comprise means for automatically terminating con- 
tact with all other keystation means in said system 
for a given keystation means associated with said 
given data input means when said keep alive signal 
periodically provided from said associated given 
data input means is not provided. 

In the first aspect of the invention as set out in 
Claim 1, the interface means may comprise a 
uniquely identifiable local data base for initially 
collecting trading ticket information relating to both 
said automatically matched trades for said trading 
instruments and video conversational negotiated 
trades for said trading instruments, and means for 
communicating said collected trading ticket infor- 
mation to a remote back office data base; whereby 
a common ticket generation scheme may be em- 
ployed in said integrated trading system for said 
trading instruments irrespective of the type of 
trade. The interface means may further comprise 
and integrated terminal controller means connec- 
tably disposed between said keystation means, 
said first communication means, and said uniquely 
identifiable local data base for selectively interfac- 
ing said keystation means with said first commu- 
nication means. Alternatively, the interface means 
may further comprise means for initially collecting 
said trading ticket information corresponding to 
said trades as self-contained integral trading ticket 
records and storing said self-contained integral 
records at said uniquely identifiable local data 
base. The collecting and storing means may further 
comprise means for storing said self-contained in- 
tegral records at said uniquely identifiable local 
data base unique identification and a sequential 
number corresponding to the order of confirmation 
of each of said trades at said local data base. The 
sequential numbers may be independent of the 
type of trade conducted through said integrated 
system. The system may further comprise means 
for retrievably requesting trading tickets from said 
local data base for providing said trading tickets to 
said remote back office data base independent of 
the type of trade involved. 

!n the first aspect of the invention as set out in 



Claim 1, the system my further comprise a host 
computer means for maintaining a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 

5 system by trading instrument, at (east one of said 
first plurality of keystation means comprising a 
transaction originating keystation means for provid- 
ing a bid on a given trading instrument to said 
system for providing a potential matching transac- 

w tion and at least one of said second plurality of 
keystation means comprising a counterparty 
keystation means for providing an offer on said 
given trading instrument involved in said potential 
matching transaction, said first communication 

75 means interconnecting said host computer means, 
said transaction originating keystation means and 
said counterparty keystation means in said inte- 
grated system for enabling data commnication 
therebetween for effectuating said automatically 

20 provided matching transactions. The host computer 
means may comprise means for processing said 
matching transaction for a given trading instrument 
in time order entry to said system. Alternatively, 
both said transaction originating keystation means 

25 and said counterparty keystation means for said 
potential matching transaction may each have an 
associated local data base keystation book com- 
prising a subset of said host book. The keystation 
means associated with said potential matching 

30 transaction may comprise means for displaying 
said associated keystation book on video display 
means. Alternatively, the content of each of said 
keystation books may have an associated display 
depth range controllable by said host computer 

35 means and being updatable by transaction update 
broadcast messages received from said host com- 
puter means through said first communication 
means. The transaction originating keystation 
means and said counterparty keystation means 

40 comprise means responsive to said received trans- 
action update broadcast messages for updating 
said associated keystation books and means for 
providing directed messages to said host computer 
means corresponding to said bid and offer, respec- 

45 tively, said direct messages updating said host 
book. The host computer means may comprise 
means for conditionally providing said transaction 
broadcast update meassages to said keystation 
means associated therewith in response to the 

so presence of an update condition, said update con- 
dition comprising updating of said host book and 
said received bid or offers within said host book 
having a relative value compared with other bids or 
offers within said host book which is within said 

55 keystation book display depth range of relative 
values; whereby controllable subsets of a dis- 
tributable system trading book may be selectively 
provided to trading keystations in said integrated 
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system from the host for controllably masking the 
available trading market for said automatically 
matched trades. 

In the first aspect of the invention as set out in 
Claim 1, the data input means may further com- 
prise means for periodically providing a keep alive 
signal to said interface means, said interface 
means comprising means responsive to said pe- 
riodically provided keep alive signal for automati- 
cally terminating contact with all other keystation 
means in said system for a given keystation means 
associated with said given data input means when 
said keep alive signal periodically provided from 
said associated given data input means is not 
provided. 

In the second aspect of the invention as set out 
in Claim 8, the common data input means may 
further comprise means for toggling between said 
matching trades and said video conversational ne- 
gotiated trades for selectively effectuating said 
trades via said first keystation means. The first 
keystation means may further comprise means for 
selectively varying the content of the display on 
said common video display means in response to 
said toggling of said data input means. The means 
for selectively varying the display content of said 
common video display means may comprise 
means for varying the format of said display on 
said common video display means in response to 
said toggling of said data input means. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise a 
second integrated terminal contorller means con- 
nectably disposed between at least a second 
keystation means and said data communication 
network for selectively interfacing said second 
keystation means with said data communication 
network, said second keystation means comprising 
a common video display means capable of display- 
ing both said bids and said offers associated with 
said matching transactions and said video con- 
versational textual data messages associated with 
said negotiated trades, and a common data input 
means for selectively inputting both said video con- 
versational textual data messages to said data 
commnication network through said second inte- 
grated terminal controller means for effectuating 
said video conversational negotiated trades and 
said bids and said offers to said data commnication 
network through said second integrated terminal 
controller means for effectuating said automatically 
provided matching transactions. 

In the second aspect of the invention as set out 
in Claim 8. the integrated terminal controller means 
may comprise a concentrator computer means for 
interfacing said bids and said offers with said data 
communication network. Alternatively, it may com- 
prise a conversation server means for interfacing 



said video conversational textual data messages 
with said data communication network. In this case, 
the conversation server means may further com- 
prise common data base means for integrating 

s trade data relating to both said bids and said offers 
and said video conversational textual data mes- 
sages. Alternatively, the integrated terminal control- 
ler means may further comprise a concentrator 
computer means for interfacing said bids and said 

w offers with said data communication network. The 
integrated terminal controller means may further 
comprise a local area network means for tieing said 
conversation server means and said concentrator 
computer means together. The first keystation 

75 means may comprise a terminal computer means, 
said terminal computer means being tied to said 
local area network means. 

In the second aspect of the invention as set out 
in Claim 8, the first keystation means may com- 

20 prise a computer means. The data input means 
may further comprise means for periodically pro- 
viding a keep alive signal to said first keystation 
computer means, said first keystation computer 
comprising means responsive to said periodically 

25 provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said first keystation means associated with 
said data input means when said keep alive signal 
periodically provided from said data input means is 

30 not provided. The means responsive to said pe- 
riodically provided keep alive signal comprises 
means for automatically terminating contact with all 
other keystation means in said system for said first 
keystation means associated with said given data 

35 input means when said keep alive signal periodi- 
cally provided from said associated data input 
means is not provided. 

In the second aspect of the invention as set out 
in Claim 8, the integrated terminal controller means 

40 may comprise a uniquely identifiable local data 
base for initially collecting trading ticket information 
relating to both said automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instru- 

45 ments, and means for communicating said col- 
lected trading ticket information to a remote back 
office data base; whereby a common ticket genera- 
tion scheme may be employed in said integrated 
trading system for said trading instruments ir- 

so respective of the type of trade. The integrated 
terminal controller means may further comprise 
means for initially collecting said trading ticket in- 
formation corresponding to said trades as self- 
contained integral trading ticket records and storing 

55 said self-contained integral records at said uniquely 
identifiable local data base. Alternatively, the in- 
tegrated terminal controller means may comprise a 
conversation server means for interfacing said vid- 
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eo conversational textual data messages with said 
communication network. The conversation server 
means may comprise means for communicating 
said collected trading ticket information to said 
remote back office data base. 

In the second aspect of the invention as set out 
in Claim 8, at least said first keystation means may 
further comprise pointer means for locating data 
display areas in a windowed textual video display 
on said video display means, and storage means 
for retrievably storing a plurality of unique keysta- 
tion contact signals capable of initiating conversa- 
tion contact with at least one of said other keysta- 
tion means through said data communication net- 
work, each of said other keystation means having a 
unique associated identification code, said keysta- 
tion contact signals corresponding to said unique 
associated identification codeSi said windowed tex- 
tual video display comprising a windowed display 
of at least one of said unique associated iden- 
ficiation codes, said pointer means comprising 
means capable of locating said windowed display 
of said unique associated identification code in said 
windowed textual video display and providing a 
conversational contact message signal to said 
keystation storage means in response thereto for 
retrieving said unique keystation contact signal cor- 
responding to said located unique associated iden- 
tification code for providing a calling signal to said 
corresponding keystation means through said data 
commnication network. The pointer means may 
comprise a mouse. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise inter- 
face means comprising said integrated terminal 
controller means and a uniquely identifiable local 
data base for initially collecting trading ticket in- 
formation relating to both said automatically 
matched trades for said trading instruments and 
video conversational negotiated trades for said 
trading instruments, and means for communicating 
said collected trading ticket information to a remote 
back office data base, whereby a common ticket 
generation scheme may be employed in said in- 
tegrated trading system for said trading instru- 
ments irrespective to the type of trade. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise a host 
computer means for maintaing a host book data 
base comprising all of the active bids and offers 
associated with said matching transactions in the 
system by trading instrument, at least said first 
keystation means comprising a transaction originat- 
ing keystation means for providing a bid on a given 
trading instrument to said system for providing a 
potential matching transaction and at least on of 
said other keystation means comprising a counter- 
party keystation means for providing an offer on 



said given trading instrument involved in said po- 
tential matching transaction, said data communica- 
tion network interconnecting said host computer 
means, said transaction originating keystation 

5 means and said counterparty keystation means in 
said integrated system for enabling data comm- 
nication therebetween for effectuating said auto- 
matically provided matching transaction. Both said 
transaction originating keystation means for said 

w potential matching transaction each have an asso- 
ciated local data base keystation book comprising 
a subset of said host book. Alternatively or in 
addition, both said transaction originating keysta- 
tion means and said counterparty keystation means 

75 for said potential matching transaction each have 
an associated local data base keystation book com- 
prising a subset of said host book. 

In the second aspect of the invention as set out 
in Claim 8, the data input means may further 

20 comprise means for periodically providing a keep 
alive signal to said integrated terminal controller 
means, said integrated terminal controller means 
comprising means responsive to said periodically 
provided keep alive signal for automatically termi- 

25 nating contact with all other keystation means in 
said system for said first keystation means asso- 
ciated with said data input means when said keep 
alive signal periodically provided from said asso- 
ciated data input means is not provided. 

30 In the third aspect of the invention as set out in 
Claim 9, the method may further comprise the step 
of sharing the use of said data input means at said 
given keystation means for inputting said bids and 
said offers associated with said matching transac- 

35 tions and said video conversational textual data 
messages associated with said video conversa- 
tional negotiated trades. Whether it does or not, the 
method may further comprise a step of integrating 
initial access to both said matching trades and said 

40 video conversational negotiated trades in said sep- 
arate networks. Separate networks may be for the 
given keystation means for enabling the given 
keystation means selectively to effect both said 
automatic matching trades and said video con- 

45 versational negotiated trades through said separate 
networks. 

In the third aspect of the invention as set out in 
Claim 9, the method may further comprise a step 
of sharing the use of said data input means for a 

so given keystation means for selectively providing 
transactional data with respect to both said auto- 
matic matching trades and said video conversa- 
tional negotiated trades to said system. In the third 
or fourth aspects of the invention as set out in 

55 Claims 9 and 10 respectively, the method may 
further comprise a step of retrievably storing com- 
pleted trades from both said automatic matching 
trades and said video conversational negotiated 

25 
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trades together. 

In the fourth aspect of the invention as set out 
in Claim 10, the method may further comprise a 
step of commonly collecting trading ticket informa- 
tion relating to both said automatically matched 5 
trades for trading instruments traded through said 
first data communication network and said video 
conversational negotiated trades for trading instru- 
ments traded through said second data commu- 
nication network. There may be a further step of 10 
communication said commonly collected trading 
ticket information to a remote back office data base 
irrespective of the type of trade effectuated through 
said integrated terminal controller. Said commu- 
nicating step may further comprise the step of 15 
communicating said collected trading ticket infor- 
mation as self-contained integral trading ticket 
records. 

In the fourth aspect of the invention as set out 
in Claim 10, the method may farther comprise the 20 
steps of maintaining a host book data base com- 
prising the active bids and offers associated with 
said matching transactions by trading instrument, 
and interfacing said given keystation means with 
said host book data base through said integrated 25 
terminal controller for effectuating said automati- 
cally provided matching transactions. Whether it 
does or not, the method may further comprise the 
step of processing said matching transactions for a 
given trading instrument in time order entry to said 30 
first data commnication network, when it does com- 
prise the step of maintaining a host book data 
base, it may further comprise a step of locally 
storing a subset of said host book data base at 
said given keystation means associated with said 35 
potential matching transactions. It may then com- 
prise a step of providing transaction update broad- 
cast messages to said given keystation means 
through said first data communication network and 
said integrated terminal controller for updating said 40 
locally stored subsets in accordance with said 
transactional data relating to said automatic match- 
ing transactions. The transaction update broadcast 
message providing step may further comprise the 
step of selectively providing said update messages 45 
in response to a predetermined condition. The up- 
date message selective providing step may com- 
prise the step of controllably masking the available 
trading market for said automatically matched 
trades at said given keystation means. 50 

In the fourth aspect of the invention as set out 
in Claim 10, the given keystation means may com- 
prise computer means, said method further com- 
prising the step of periodically providing a keep 
alive signal from said given keystation data input 55 
means to said given keystation computer means, 
and deleting said bids and offers provided from 
said given keystation means when said keep alive 



signal is not periodically provided from said given 
keystation data input means. The method may then 
further comprise a step automatically terminating 
contact with all other keystation means in said 
system for said given keystation means when said 
keep alive signal is not periodically provided from 
said given keystation data input means. 

Claims 

1. An integrated trading system capable of provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties at dif- 
ferent locations and video conversational negoti- 
ated trades for trading instruments between poten- 
tial counterparties at different locations over a first 
communication means, said automatic matching 
trades comprising trades in, which bids from poten- 
tial counterparties are automatically matched 
against offers from potential counterparties for giv- 
en trading instruments for automatically providing 
matching transactions in order to complete said 
automatic matching trades for said given instru- 
ments, said video conversational negotiated trades 
comprising trades in which video conversational 
textual data messages are selectively routed be- 
tween potential counterparties with respect to bids 
and offers for given trading instruments for en- 
abling discretionary conversational messages to be 
exchanged between said potential counterparties in 
order to negotiably completed said video conversa- 
tional negotiated trades, said integrated trading 
system comprising a first plurality of keystation 
means; and a second communication means, said 
first plurality of keystation means being selectively 
connectable to said first communication means 
through said second communication means for en- 
abling said first plurality of keystation means to 
selectively communicate with a second plurality of 
keystation means at said different locations to ef- 
fectuate said matching trades and said video con- 
versational negotiated trades, at least a first one of 
said keystation means in said first plurality being 
capable of effectuating at least said automatic 
matching trades and at least a second one of said 
keystation means in said first plurality being ca- 
pable of effectuating at least said video conversa- 
tional negotiated trades, said first one of said 
keystation means in said first plurality comprising 
video display means capable of displaying at least 
said bids and said offers associated with said 
matching transactions and a data input means for 
selectively inputting said bids and said offers to 
said first communication means through said sec- 
ond communication means for effectuating said 
automatically provided matching transactions, said 
second one of said keystation means in said first 
plurality comprising video display means capable 
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of displaying said video conversational textual data 
messages associated with said negotiated trades 
and a data input means for selectively inputting 
said video conversational textual data messages to 
said first communication means through said sec- 
ond communication means for effectuating said 
video conversational negotiated trades, said second 
communication means comprising interface means 
connectably disposed between said first one of 
said keystation means in said first plurality and 
said first communication means and said second 
one of said keystation means in said first plurality 
and said first communication means for selectively 
interfacing said first one of said keystation means 
in said first plurality and said second one of said 
keystation means in said first plurality with said 
keystation means in said second plurality through 
said interface means and said first communication 
means; whereby both automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instruments 
may be conducted through said integrated trading 
system. 

2. An integrated trading system in accordance with 
claim 1 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

3. An integrated trading system in accordance with 
claim 1 wherein said second communication means 
comprises a common communication path for said 
matching trades and said video conversational ne- 
gotiated trades. 

4. An integrated trading system in accordance with 
claim 3 wherein said second communication means 
common communication path comprises a local 
area network means. 

5. An integrated trading system in accordance with 
claim 1 wherein at least said video display means 
for said first one of said keystation means in said 
first plurality further comprises means capable of 
displaying said video conversational textual data 
messages associated with said negotiated trades 
for effectuating said matching trades. 

6. An integrated trading system in accordance with 
claim 5 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

7. An integrated trading system in accordance with 
claim 5 wherein at least said data input means for 
said first one of said keystation means in said first 
plurality comprises a common data input means for 
selectively inputting both said video conversational 
textual data messages to said first communication 
means through said second communication means 
for effectuating said video conversational negoti- 
ated trades and said bids and said offers to said 



first communication means through said second 
communication means for effectuating said auto- 
matically provided matching transactions. 

8. An integrated trading system capable of selec- 
s tively providing both automatic matching trades for 

trading instruments between potential counterpar- 
ties and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a data communication network, said auto- 

w matic matching trades comprising trades in which 
bids from potential counterparties are automatically 
matched against offers from potential counterpar- 
ties for given trading instruments for automatically 
providing matching transactions in order to com- 

75 plete said automatic matching trades for said given 
instruments, said video conversational negotiated 
trades comprising trades in which video conversa- 
tional textual data messages are selectively routed 
between potential counterparties with respect to 

20 bids and offers for given trading instruments for 
enabling discretionary conversational messages to 
be exchanged between said potential counterpar- 
ties in order to negotiably complete said video 
conversational negotiated trades, said integrated 

25 trading system comprising at least a first keystation 
means selectively connectable to a plurality of oth- 
er keystation means through said data communica- 
tion network for enabling said first keystation 
means to selectively communicate with said other 

30 keystation means to effectuate said matching 
trades and said video conversational negotiated 
trades; and integrated terminal controller means 
connectably disposed between said first keystation 
means and said data communication network for 

35 selectively interfacing said first keystation means 
with said data communication network, said first 
keystation means comprising a common video dis- 
play means capable of displaying both said bids 
and said offers associated with said matching 

40 transactions and said video conversational textual 
data messages associated with said negotiated 
trades, and a common data input means for selec- 
tively inputting both said video conversational tex- 
tual data messages to said data communication 

45 network through said integrated terminal controller 
means for effectuating said video conversational 
negotiated trades and said bids and said offers to 
said data communication network through said in- 
tegrated terminal controller means for effectuating 

so said automatically provided matching transactions; 
whereby both automatically provided matched 
trades for said trading instruments and video con- 
versational negotiated trades for said trading instru- 
ments may be selectively conducted over said 

55 integrated trading system. 

9. An integrated trading system method for provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties and 
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video conversational negotiated trades for trading 
instruments between potential counterparties over 
separate networks relating to said automatic match- 
ing trades and said video conversational negotiated 
trades, each of said networks comprising a plurality 
of keystation means selectively connectable to 
each other through said separate network, said 
keystation means comprising data input means and 
video display means; said method comprising the 
steps of sharing use of said video display means 
for a given keystation means for enabling said 
given keystation means to transact both said auto- 
matic matching trades, in which bids from potential 
counterparties are automatically matched against 
offers from potential counterparties for given trad- 
ing instruments for automatically providing match- 
ing transactions in order to complete said auto- 
matic matching trades for said given trading instru- 
ments, and said video conversational negotiated 
trades, in which video conversational textual data 
messages are selectively routed between potential 
counterparties with respect to bids and offers for 
given trading instruments for exchanging discre- 
tionary conversational messages between said po- 
tential counterparties for negotiably completing said 
video conversational negotiated trades; and selec- 
tively interfacing said given keystation means with 
both of said separate networks for selectively con- 
necting said given keystation means to keystation 
means in both of said separate networks for en- 
abling said given keystation means to selectively 
transact both said automatic matching trades and 
said video conversational negotiated trades through 
said separate networks; whereby both said auto- 
matically provided matching trades and said video 
conversational negotiated trades may be conducted 
at said given keystation means for trading desired 
trading instruments irrespective of the type of 
trade. 

10. An integrated trading system method for pro- 
viding both automatic matching trades for trading 
instruments between potential counterparties over a 
first data communication network to a plurality of 
keystation means selectively connectable to each 
other through said first data communication net- 
work and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a second data communication network to 
a plurality of keystation means selectively connec- 
table to each other through said second data com- 
munication network, said keystation means com- 
prising data input means and video display means, 
said keystation means being selectively connec- 
table to both said first and second data commu- 
nication networks through interface means for se- 
lectively interfacing said keystation means with 
each other through said first and second data com- 
munication networks, said method comprising the 



step of providing transactional data between said 
keystation means and said potential counterparties 
relating to both said automatic matching transac- 
tions and said video conversational negotiated 

5 trades through a common integrated terminal con- 
troller means for enabling a given keystation means 
to selectively effectuate both said automatic match- 
ing transactions and said video conversational ne- 
gotiated trades through said common integrated 

10 terminal controller to said first and second data 
communication networks, respectively. 
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TABLE A 



•include <stdio.h> 
•include <und«f.h> 
•ondtf HOHEHHGR 
•und«f NOVXNMESSAGES 
•include <wtndows.h> 

• include "a'msg.h"* 

• include "a3ctrl .h" 
•include "dartif ,h" 
•Include "dlalogid.h* 
•include "pkt_logn.h M 
•include Vdlsjdl I .h" 

• include "rdis'cll.h*' 
•include "a3netl tb.h" 
•include 'fatal. h" 



typedef enum 
( 

DART, 
ROTS 
) APPLICATION; 

typedef enum 
{ 

sj3uerysent, 

s'ouerywait, 

s~logoffsent, 

s'logopfwait, 

sj.0ggedoff, 

s oaruogsingon , 
s'rotsloggingon, 

S_ACTIVE. 

s~oartactive, 

SJNHIBITEO. 
s"lNACTlVE 
) ROl STATES; 



/• » se^t a ROIS_QUERYL0GOFF and an waiting for a reply */ 

/* r»a*e cc: a RGISJDLRESONSE and waiting for other »/ 

/• have se~c a ROISJ.OGOFF to both parties •/ 

/■ wa'l»<*g for the other partie to reply */ 

/• bof parties are logged off •/ 

/■ "5 for DART to logon •/ 

/• -a*: —i f o r ROTS to logon «/ 

•'■ oct- sa'fes are logged on and active •/ 

/• oa-- z"\y is active •/ 

/• inhibited •/ 

. • : -a- tmg for dialog data »/ 



/• ROI states •/ 

ROI STATES state = S 



/• used for debugging •/ 
•if defined (DEBUG) 

Char *pState [] = { S QUE*vs£n: . 5 QUE3YVAIT" , *S LOGOFFS ENT", "S LOGOFFVAlT" , "SJ.OGGEDOFF" , -S_0ARTlOGG1NGOn 
"S~RDTS»0GGt>*3CN "7 ^ACTIVE', "S^DART ACTIVE* , "S^IKMIBITEO- , ^"INACTIVE - } ; 

•end if 



/• debug macros «/ 
•define LlT(s) is 
•define LlTERAL(n) LlTJn) 

•define WriERE FKE . : "RAt.(__UNE_) 



static HV4ND hKndOialog = VAc. 

static LOGON J)ATA LogonOata = *;*; -0} .{3} .{0} . (0} ,{0)); 
static long Logoff Reason = 0. 

/• ma<iown Unit if I0*S •* 
•define max_Oartio i'.l 
•define hax~R3TSI0 

/• id's sent out to apps •/ 
static wORO Oartld - 0; 
static wORO Rdtsld = 0; 



static votd cOCAL SetRDISt&te , Ar. \ _S'-*ES s); 

static void LOCAL Tel IROTSLogcn ;.z~g * p aram) 

static void EndLogonOialog {void, 

static WORD LOCAL GetNewtd (APPu:Ci*:Cv *po) . 

static void LOCAL SendLogcff (to^o ;3«son> r 



/,.,...,............,•..»...«. ............ ..t........ ........... 

/• nodule : rdilogon.c 

/• Routine: void LOCAL CialogOata ;-*NDLE nH«m) 

/■ this procedure is sent tr»e logon data from setup ano then 

/» starts the logon process *ith DART and ROTS 

/• Return : 
/• 
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/,...*..........,..•..*...*....•,.....•«,. .......... ..................../ 

void LOCAL Dialogue ta (man OLE hHem) 
{ 

LPLOGONJJATA lp * (LPlOGON_DATA) GlobalLock (hMem); 
LogonOata » »lp; 
Global Unlock (hHan) ; 

/• long parameter is Handle :of fset. 1 am roc going to need an offset 

* at the moment so offset is aero 
•/ 

/• sat fLag to tell myself that reply will be from OART as cne oart 

* logs on before ROTS 
•/ 

SetROIState (S_DAATL0GGING0N) ; 

/• check result from logon message •/ 

switch ((WORD) CtrlSendKessage (HOD 0ART t R0I5 LOGON, 0, MAKElCNG (0, rMem))) 
{ 

/* Can't log on because printers have failed •/ 
case lOJ*INTERSFAIi£D: 

SetROIState (SJ.OGGEDOFF); 

CtrlSendMessagi" (HOD SETUP. OK ERRORTExTOIAlOG, hwnaDialog, (long) TC PRINTERS_FAILE0) ; 
break; 

/* Can't log on since ROTS is oresent and 

* the ROTS trade printer is not installed */ 
case L0_PRINTERN0T INSTALLED: 

SetRDI State (SJ.OGGEDOFF) ; 

CtrLSendHessage (HOD^SETuP, 0H_ERR0RT£XT0IAL0G, hWndOialog, (long) TC_N0_R0TS.PR INTER) ; 
break; 

case L0J5K: 
break; 

case L0_BA0DATA: 

DartFatalExit (FTL_BAD_».dCN_DA.TA) ; 
break; 

case L0_A LREAOYON : 

DartFatalExit (FTL_ALREA>'_CN) ; 
break ; 

default: 

DartFatalExit (FTL 8A0 RE^iy) , 
break; 

} 

) 

/.»..««,«..,•.,,.....•.,..........,,»,,«,.,...,,.,.....,.,,.,....,....... / 

/• Hodule : rdi logon. c */ 
/* Routine: void LOCAL Dialognandle (*wnD hwnd) •/ 
/* gets the handle to t-e oiaiog disoiayea Dy se*uo, this ^3"sve V 
/* is then used to pass "essages to the diavog, *e e"©*- <ness*3es 
/* Return : void • / 

/• •/ 
/.•«...,........,..,,..,....,.. ......... ...... ......... * .../ 

void LOCAL DialogHandle (hwnd h-~a; 
{ 

hWndDialog = hWnd; 

) 



/••**......••.••...*........... 

/• Hodule : rdi logon. c 

/• Routine: static void EndLogorC*a;og (void) 

/• sends a message to tr-e setup modvie to end the icgon dialog 

/« 

/* Return : void 
/• 

/.»*.t*....*«....M....... 

static void EndLogonOialog (void) 
{ 

CtrlSendMessage (MOO SETUP. Dm £\-2:H0G, -*-»dDi alog , 3D; 

) 



/.•I..*.*...*.....,,*...........,.....................,.. 

/• Module : rdi logon. c 

/• Routine: static WORD LOCAL Getne-to (APPLICATION App) 

/» allocates a new id for RDTS or DART 

/• 
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/• Return : new id 

/• ./ 
/• — """ — •««.*•*......................•.....•.».•.•.•.„.....•../ 

static WORD LOCAL GetNewtd (APPLICATION App) 

static WORD OartIO = 0; 

static wORO ROtSIO = MAXJ)ARTID + 1; 

switch (App) 
{ 

case OART: 

/* increment counter and check for roll over «/ 
OactID+*; 

tf (OartIO >= MAX_0ARTIO) 

DartID =0; 
• if defined (DEBUG) 

printf ("Oart id = Xd\n", OartIO); 
*endif 

return OartIO; 
case ROTS: 

/• Increment counter and check for roll over •/ 
ROTSI0++; 

if (ROTSIO >= MAX_ROTSIO) 

RDTSIO = MAX OARTIO ♦ I; 
•if defined (DEBUG) 

printf ("ROTS id s %d\n". ROTSIO); 
*endif 

return ROTSIO; 

aef auit: 

fatalExit (FTl_ INCORRECT APP); 
break; 

) 



/ 



/• nodule : rdi logon. c *^ 
/• Routine: void LOCAL Key Boar detached ( VO id) «/ 
/* called when the kevooard is detached , and then takes action «/ 

/* according to RDI scec «/ 

/• Return ; void 

':■ z 

void ;.OCAL KeySoaroOetacned (void) 
( 

■if defined (DEBUG) 

pr i ntf { " OM_KBDOETACH\n- ) ; 
•endif 

switcn (state) 
{ 

case S_INACTIVE: 
case S~0ARTAC7IVE: 
case SJ.0GGE00FF: 
case SJ3UERYSENT: 
case SJ3UERYVAIT; 
case s'lOGOFFSENT: 
case s"lOCOFFWAIT: 
case S^ACnvE: 
case s'oaRTlOCGInCON; 
case S>0TSLOGGlNG0N: 

SetROIState (SJ.0G0FFSENT ) ; 

SerxJlogoff ((iong) lF_0E t aCm); 

oreak; 

} 

) 

/a................ .........•..........„„„...„.....„...*„....., 

/• Module : rdi logon. c •/ 
/• Routine: void LOCAL KeyBoardState (-OR0 KeyBoardState) •/ 
called when the keyboard state changes and then ta*es action •/ 
/• according to ROl spec t/ 

/« Return : €/ , 



void LOCAL KeyBoardState (WORD KeyBoaroState ) 

*if defined (DEBUG) 

printf ("0M KBDSTATE Xd\n" , KeyBoaroState); 
•end if 
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/» »f string not there or set to 1 then process message •/ 
if (GetProfllelnt (~ART3\ "KeepM iv#- , l) s « 0) 

• if defined C DEBUG) 

printf ("ignore keep iLtveVn - ); 
•end if 
return; 

) 

switch (state) 
{ 

case S_lNACTlve: 
case SJ)AR7ACTIVE: 
case SJ.0GGE0OFF; 
case S_QU£RYSENT: 
case S^OUERYWAIT: 
case S~tOGOFFSENT: 
case SJ.0G0FFVAIT: 
case S_ACTIVE: 
case S^OARTLOGGINGON: 
case SJIOTSLOGGINGON: 

SetROlState (SJ.0GOFFSENT) ; 

if (Key Boa restate ==0) 

Logoff Reason = LF KBOFail; 

else 

Logoff Reason = LF_KB0CK; 

•if defined (DEBUG) 

printfC Keyboard state = Xd\n" , Logoff Reason) : 
•endif 

SendLogoff ( Logoff Reasc , 
break; 

) 

} 



/* Module ; rdilogon.c »•••«•••»•••••••••••/ 

/• Routine: void LOCAL «DIs.==«-. y (HWNO hwnd , WORD nResult. long iParam) 1/ 

I handled the R0:s_.:/tEPLY messages, If from dart and is success •/ 

/• then ROTS logs cr» 



v»«ii nui3 togs cr» m * 

/» Return ; void # ^ 

•/ 



void LOCAL ROISLoRepiy (HWNQ p-no, wORO nResult, long IParam) 

•if defined (DEBUG) 

pnntf ("R01S LO REPLYNn ); 
•end if 

switcn (state) 
( 

case SJURTiOCGlNGON: 

/• first check resjit c* logon •/ 

switch (nResult) 

{ 

case L0_0X: 

SetROlState (SJlOTSlCOGlNGON) ; 
TellROTSLogon (iPara-.. 
break; 

case 10JIEJECTE0: 

/• logon has failed s= 90 Dack to logged of status •/ 
SetROlState (S^LOGGEOC'F) . 

break endMeSSa9C (M00 - 5£ " uP ' DM-ERRORTEXTOIALOG. hWndDialog, (long) TC.9AD0UMD); 

case LO^ALREAOYON: 

SetROlState (S^LCGGEX"?); 

CtrlSendHessage (MfJOJE^p, Cm_ E RRORT EX T D I A LOG , hWndOlalog, (long) TC OLR ON TWICE); 
break; - - - * 

) 

break; 

/• dont remove dialog as its not on o»splav •/ 
case SJURTACTIVE: 

/• first check result of logon «/ 

switch (nResult) 

C 

cast LO^NQN TRADING: 
case LO^LINEOOWH: 
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/« ROTS report* Une down but DART can carry on V 
•if defined (DEBUG) 

prmtf TROTS line down\n"*); 
•end if 

SetROIState (S OARTACTIVE); 
break; 

case L0_0K: 

SetROIState (S_ ACTIVE) ; 
• if defined (DEBUG) 

prmtfCAOt: Everyoody Logged on and happy !«'!\n")* 
•end if * 
.break; 

case I 0_BAD_ TRADER: 
break; 

case tO_INHIBITED: 

/• cant display a message as logon box is not displayed »/ 
break; 

case 10J.0G0FF: 
case LO~REJECT£D: 
break; 

} 

break; 

case S — RDTSLOGG ING0N : 

/« first checK result of togon »/ 

switch (nResult) 

{ 

case L0J*0NTRA0ING: 
case LO^LINEOOWN : 

/• RDTS reports U"e cc-n but DART can carry on */ 

•if defined (DEBUG) 

print* ("ROTS U^e =c-n\n~); 

•endif 

SetROIState (5_Dar;ac::.E) ; 
EndlogonOialog~(). 

CtrlSendMessage («03_;.i3T t rqiS aulOGGEOON, 0 OL)* 
break; " ~ ' * 

case LO_OK: 

SetROIState (S^ACTIVE), 
EndLogonOialog (); 

CtrlSendMessage (m00_3~RT , QOIS ALLL0GGED0M, 0. OL); 
RDISSencMessage (nwocROrs, RDIS~ALLlOGGEDON. o' OL) * 

RDISSendMessage (r.WndRCrs. UM_A0IS,F0CUS SWITCH. RDJS ACTIVATE RDTS. OL); 
•if defined (DEBUG) " ~ " 

pr >ntf("RDI: Everybody logged on and happy I'i'VT); 
*endi f 
break; 

case L0_8A0_TRA0ER: 

SetROIState (SJ.CGGEDOFF); 
Dartld = GetNeCld (CART), 

CtrlSendMessage («CD_CART. RD15J.0G0FF, Dartld. (long) LF USER) ; 

CtrlPostMessage ("OD.SETUP. 0MJRR0R7EXTDIAL0G. hWndOialoi. (long) TC 8A0 TRADER ID) ; 

/• Tell dialog handler to display error */ " " 

break; 

case LO_tNHIBIT£D; 

/■ log DART tack eff * 
SetROIState (SJ.CGGE0OF?) . 
Oartld = GetNewId (Cart ) ; 

CtrlSendMessage (KODJJART, RDIS LOGOFF. Dartld. (long) LF USER) ; 

b^ak*^""" 9 * (K)D - SETUP * ^ M _ERR0R T E X TO I A LOG , hWndDlaloi, (long) TC_RDTS.INHI8ITE0) ; 

case 10J.0G0FF; 

/• togon has faHed so go sack to logged of status */ 
SetRDIState (SJ.0GGED0FF) ; 
Dartld * GetNewId (OART ) , 

CtrlSendMessage (HO0J)ART, ROIS LOGOFF, Dartld. (long) LF USER) * 
break; " 

case 10JIEJECTED: 

f * Ued (t>a<3 pass -° ra > *° go back to togged of status •/ 
SetROIState (S_L0GGED0FF) ; 

Dartld = GetNewId (CART); 

CtrlSendMessage (MODJJART, POIS LOGOFF, Dartld, (long) LF USER) ; 

CtrlSendMessage (M00_SETuP. CM.ERRORTEXTDUiOG. hWndOialoi. (long) TC BAD PASSWORO) ; 
break: — — 
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case L0_ALREADYON : 

SetROIStatt (SJ.OGGE0OFF); 

CtrlSendMessage (MOO_S£TuP. OM_ERRORTEXTOIALOG. hWndDiatog, (long) TC OLR ON TWICE) ; 

SendLogoff ((long) LFJMPERATIVE) ; 

break; 

) 

break; 

} 

) 



/ 



/» Module : rdHogon.c t/ 
/* Routine: void LOCAL ROISLoggecOf f {hwnD hWnd, WORD -Id) •/ 
/* handles the ROIS LOGGED OFF messages •/ 

" V 
/• Return : void ,/ 

/• • ./ 
• ••«••• / 

void LOCAL RDISLoggedOff (Mwwo hw«d. WORD wld) 

»1f defined (DEBUG) 

prnntf ("RDIS LOGGED OFF\n"), 
■endif 

switch (state) 
{ 



case SJ)ART ACTIVE: 
•if "defined (DEBUG) 

printfCUne down a^d 'ct3 logged off\n")- 
lend if 
break; 



case SJ.OGGEDOFF: 
case S~ACTIVE: 

/• if in this state tne*- -_-•_> .scoff has been aborted •/ 
break; 

/• first reply from someone • 
case S_LOGOFFSENT : 

if (wld == Oartld || wi = =3:sld) 
SetfiOI state (S J.0GOF-*- ; * ■ , 

break; ~ 



/* second reply therefore pes dialog •/ 
case SJXGOFFWAIT: 

SetROIState (S_LOGGEDOFF) . 

/• only for debugging should not be send unless both parties aggre* »/ 
if (ROTSPresent) 

CtrlPostMessage (MOCSETuP, OH STARTDIAlOG, hWnd, HAKElCNG (SO LOGON, 0)); 
else 

CtrlPostMessage (H0D_SETU? , OM STARTOIALOG, hWnd, HAKELCNG (SO CHANGE DEALER, 0)); 
break; ~ * 

} 

) 



/•.*■.................•....,...,........„..„.,,.,.,.,,„„ 

/* Module : rdl logon. h 

/* Routine: void LOCAL RDISlogcf *He=-est (hwnO hWnd) 
/* processes a request •'=■3 DART or ROTS to log off 

/» 

/• Return : void 
/• 

/•*...*».*»•.. .......»••.....,,,.•..., 

void LOCAL ROISLogoffRequest (.o-g -eason) 

■1f defined (DEBUG) 

printf ("RDIS LOGOFFREQuE$T\n ; 
*endif 

/• if we have received a DM_STa*t message and one or other of tne events 
•^have happened then -e can start initial logon sequence 



*/ 
•/ 
V 
•/ 
•/ 
«/ 



If (GotOMStart U (ftegT imer£*pi ^ e o :; ROTSP'esent ) ) 

switch ((WORD) Reason) 
{ 

case LF_STARTUP: 

/* starting up so force logoff •/ 
/* save reason for logoff message •/ 
SetROIState (S_L0G0FFSENT) ; 



34 



EP 0 434 224 A2 



SendLogoff (Reason): 
break; 

default: 

/« save reason for logoff message •/ 
Logoff Reason = Reason; 

SetROIState (SJ2UERYSENT) ; 

/•post messages to DART and RQTS recuesttng that the/ log off •/ 
Dartld = GetNewId (OART); 

CtrlPostHessage (MODJJART, RDISJJUERYLOGOFF, Oartld, OL); 

imjst wake sure that t*e post gets through »/ 
Rdtsld s GetNewld (ROTS) ; 

while (PostHessage (hwnaRDtS, ROIS QUERYLOGOFF, Rdtsld. OL) == 0) 
printf (WHERE "RDI PostHessage failed\n"); 

break; 

) 

) 

) 

/.«".....•..„..„„„„„„.....„„....,.„„„,„ 

/* Module : rdi logon. c t/ 
/* Routine: void LOCAL ROISQUesonse (hwnO hWnd, WORD wld. WORD nResult) */ 
/» * handles ROIS QlRESPCNSE message */ 

/• " ./ 

/• Return : t * 

'■• 

void LOCAL RDISQlreson5e (hvsO —no. rfORO wld, WORD nResult) 

11 f defined (DEBUG) 

prlntfCROlS QLRESPCNSE - , 
•endif 

switch (state) 
{ 

case SJ.0GGEDOFF: 
case S~ACTIVE: 

/• if in this state ;*•» *ogoff has oeen aborted «/ 
break; 

case S OUERYSENT: 
{ 

/* check result of Lege** "--auiry •/ 

switch (nResult) 

( 

case 0L_STOP: 

SetROIState (S_AC7IVE); 

/• tell setup that t*e logoff has been aborted •/ 
CtrlSendMessage (MOD 5ET*P, Cm EXTRN DIALOG ABORTED. 0, OL); 
break; " 

case 0L_ACTIVE: 

/• abort logoff ano set *Zl state back S ACTIVE •/ 

SetROIState (S_aCT:vEI, 

if (wld =a Oartlo |i -To == Rdtsld) 

Ctrl PostHessage jv'O S=rjP, Om STaRTOIalOG. hVnd.KA<Et.ONG (SO ACTIVE CONVS, 0)>; 
break; " " 

case 0l_0K: 

if (wld — Oartlc j - : z -s =cts!d) 

SetROIState ,S Z.i- 
break; 

) 

) 

break; 

/* wait for the other pa'ty to *--oiy •/ 
case SJJUERYWAIT: 
switch (nResult) 

c 

case QL_ST0P: 

SetROIState (S^aCTIvE), 

/« tell setup tnat the loao'* -as Oeen aborted */ 
CtrlSendMessage (MOD SE**P, > EaT^h 01 a LOG ABORTEO, 0. OL); 
break; 

case 0L_ACTIVE: 

/* abort logoff and set ROI state back S ACTIVE •/ 

SetROIState (S_*CTIVE); 

1f (wld == Oartld || wld == Rdtsld) 

CtrlPostMessage (H00_SETuP. DH_STart0IAL0G, hWnd .HAKElONG (SO_ACWE CONVS, 0)); 
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break; 

case OL OK: 

C 

/• request from ROTS to remove the are you sure dialog 
» but i will leave the code in case their minds 
♦are changed 
»/ 

iif o 

WORD result; 

SetROIState (S_Inact:vE) ; 

•result = (WOROT CtriSe-x^^ge (mOO.SETUP, C8_STARTOlAtOG, hWnd, MAKE LONG (SD_AREYOUSUR£, 0)); 

/• 1f user says yea cnen fimsi logoff «/ 

If (result IOYES) 

{ 

SetROIState (SJ.OGCFFSEMT), 
SendLogoff (Logof ffieason) 
break; 

) 

/• If no then 90 back to act we «/ 
else if (result -= IONO) 
SetROrState (S ACTIVE); 



«els« 



•endif 



/• If result Is something different then do nothing ./ 
break; ' 7 

/* do it the old wav »/ 
SetROIState (S_lOGOFfsest> ; 
SendLogoff (Logof f Reason) 
break; 



> 
> 

break; 

default: 
break; 

) 

} 

/"•••.t»»»t... M ..,..,„.. ...... ....... 

/• Module : rdUogon.c ••«..»...............•......, 

/• Routine: void LOCAL ROISStatus («OR0 reason) 

/• processes the RDIS^StATuS message », 

/• Return : void 

/• •/ 
/..»».»...........,.......... . V 

void LOCAL «0ISStatus (WOR0 reason) ••« — — ■•■••■......«....•«/ 

• if defined (OEBUG) 

printf("RS STATUS td\n" reason) 
•endlf 

switch (state) 
{ 

case S_INACTIVE: 
case S~0ARTACTIVE: 
case S~QUERYSENT: 
case SJftERYVAIT; 
case S_10G0FFSENT: 
case S~L0G0FFVAIT: 
case S_ACTivE: 
case S~0ARTl0GGIKGON : 
case S_RDTSL0GGINGON: 

switch (reason) 

{ 

/* handle as if detached has ceer. aecected »/ 
case RS_ IMPERATIVE: 

Se tftOI S t a te ( S_L0G0F fs EN T ) , 

SendLogoff ((long) if lMPeR*r;.=) 

break; 

case RSJJISCONNECT: 
KeyBoardOetached (); 
break; 

case RS HOSTSHUTOOVM: 
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SetRDIStata (S OARTACTIVE); 
Rdtsld * GetNewtd (ROTS); 

ROISSendHessaga (hWndROTS, ROIS_LOGOFF, Rdtsld, (lor*g)LF_HOST$mjTOOWN) ; 
break; 

cast RS_HOSTLOGOFF : 

SetRDIState (SJiARTACWE); 
Rdtsld = GetHewld (ROTS); 

RDISSendhessagt (hWndROTS, ROISJ.OGOFF, Rdtsld, (Long)LF HOST LOGOFF) ; 
break; 

case RS_LINEOOWN: 

.SetRDIState (SJWRTACTIVE); 
Rdtsld = GetNewId (ROTS); 

ROISSendHessaga (hWndROTS, RDIS LOGOFF, Rdtsld, (Long)LF_LlNEDOWN) ; 
break; 

case RSJ.INEUP; 

/* 1 will set the state but if Una is conning up then 
* dart only is running and «e should already be In this state 
*/ 

SetRDIState (SJWRTACTlVE) ; 
Tel LRDTS Logon ToL); 
break; 



case ftSJJN INHIBIT: 

/« 1 understand that this cant happen •/ 
break; 

) 

break; 

} 

) 



/..................,.......... ..••••..„........„„.„„......... / 

/* Module : rdi Logon. c •/ 
/• Routine: static void LOCAL SetRDIState (ROI_STATES $) ■/ 
/• sets the state of tre logon code ~ •/ 

/. ./ 

/• Return : void •/ 
/• ./ 
/........ — «.«..•...•.....„....„.„...„.„.„„.„„..„...„„„..... 

static void LOCAL Set«OIState (ROI STATES s) 
{ 

•if defined (DEBUG) 



pnntfCState *s -> Xs\n\ pStatelstateJ , pState(s)); 
•end if 
state = s; 

) 



/* Module : rdi logon. c •/ 

/• Routine: static void LOCAL SendLogoff (long L Reason) •/ 

/• sends a logoff request to ROTS and OART • / 

/• ./ 

/• Return : void «/ 

/• •/ 



static void LOCAL SendLogoff (long IReason) 

Logoff Reason = I Reason; 
Sartld - GetNewld (DART) ; 

CtrlSendMessage (MODJ)ART. 3DIS LOGOFF, Dartld, Logoff Reason) ; 
Rdtsld = GetWewId (ROTS); 

ROISSendMessage (hWndROTS, R0IS_LOGOFF, Rdtsld, Logoff Reason ) ; 



..........,...„„....,.»........../ 

/* Module : rdi logon. c * •/ 

/• Routine: static void LOCAL TeUWSLogon (long IParam) «/ 
/• copies data from OART logon and instructs ROTS to logon «/ 

/« ./ 
/* Return : •/ 
/• ./ 

••«• — «• * ....... .,..,.........,.............../ 

static void LOCAL TetlROTSLogon (Long i»ara/n) 
{ 



/• log on is required so copy data and send a message to setup •/ 
HANOLE hROIcopy s HlwORD (IParam); 
int offset = LOWORD (IParam); 
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HANDLE WycOpy; 
LPL0GON_0ATA IpMycopy; 
LPL0G0N~0ATA IpftDIcopy; 
WORD LogonSource; 

hHycopy = Global Alloc (CHNO | GMEM SHARE , (long) sireof (LOGON DATA)); 
IF_FAILED_EXIT (hHycopy, FTl_NO_LOGQN_M£H) ; 
LpHycopy = (LPLOGONJJATA) GlobIlLock~(hHycopy) ; 
IF_FAUED_EXIT (IpMycopy. FTL NULL POINTER); 



switch (state) 
{ 

case S RDTSL0GGIN30N: 
{ 

tpROIcopy = (LPL0GON_0ATA) GlobaUock (hflOIcopy); 
IF_FAILED_EX1T UpftOIcooy, FTL_NULl_POINTER) ; 

/• now allow for offset if there is any, blame the designer for all this 
• necking about with offsets 
•/ 

IpftDIcopy = (LPLOGOWJWTA) ( ( LPSTR) IpftDIcopy ♦ offset); 

/• make a copy of the data •/ 
•IpMycopy = npRDIcopy; 
LogonQata - •IpftDIcopy; 

/* set packet markers V 
lpMycopy->stx = STX; 
lpHycopy->etx s. £TX; 

/« logon from dialog box •/ 
LogonSource = LGJJBOX; 
Globaiunlock (hROIcopy); 
break; 



case S OART ACTIVE: 
{ 

/' make a copy of the =a:a * recived at the last logon »/ 
■IpMycopy * LooonOata; 

/• set packet markers •/ 
IpMycopy ->stx = STX; 
tpMycopy->etx = E7X; 
/• logon from lineup •/ 
LogonSource = LGJWTO; 
break; 

} 

) " . • 

Globaiuniock (hMycosy); 

switch ((WORD) RDISSenOMessage (nwnoROTS, R0I$_L0G0N, LogonSource, HAKE LONG (0, hHycopy))) 

case LO_OK: 
break; 

case L0_8A0DATA: 

OartFatalExit (FTL_BAD_LC50NJDATA) ; 
break; 

case LO^ALREADVOS: 

OartFatalExi z (FT w ^auR£a;v qk) , 
break; 

default: 

OartFatalExit {FTL BAD R£B C y) ; . 
break; 

) 

GlobalFree (hHycopy); 
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© Integrated trading. 



© Integrated trading provides both automatic 
matching trades for trading instruments between po- 
tential counterparties and video conversational nego- 
tiated trades for trading instruments between poten- 
tial counterparties using integrated keystations (202, 
204, 206, 208) which are selectively connectable 
together. Each of the keystations (202, 204, 206, 
208) includes a data input device, such as a key- 
board (240) and a mouse (242), and an integrated 
screen display (238), with the keyboard (240) and 
the display (238) being shared for both the automatic 
matching trades effectuated by the keystation (202, 
(V) 204, 206, 208) through a matching network (220) and 
^ the video conversational negotiated trades keystation 
. (202, 204, 206, 208) through a separate conversation 
network (218). An integrated terminal controller (214, 
^ 216) is provided as a common interface between the 
^ keystations (202, 204, 206, 208) and the separate 
{v> networks (218, 220). Transaction data is provided 
^ between given keystations (202, 204, 206, 208) in 

O 

Q. 
LU 



the system (200) relating to both automatic matching 
transactions and video conversational negotiated 
trading transactions through the common integrated 
terminal controller (214, 216) which interfaces with 
the separate communication paths associated with 
the automatic matching trades (220) and the video 
conversational negotiated trades (218) effectuated by 
the keystation (202, 204, 206, 208). The integrated 
terminal controller(214, 216) comprises a conversa- 
tion server (252), a concentrator computer (254), the 
terminal computers (250) associated with the various 
keystations (202, 204, 206, 208) it serves, and a 
local area network (256) tieing them together. Initial 
access to both types of trades can be obtained at 
log on. A common ticket generation scheme for both 
types of trades is used so that trading tickets may 
be collected and communicated to a remote back 
office data base through the integrated terminal con- 
troller (214, 216), via the conversation server (252), 
irrespective of the type of trade completed. 
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